Lets kick this thing off!

Initial requirements discussion

Moderator: seaton

Lets kick this thing off!

Postby seaton » Thu Sep 20, 2007 2:30 pm

As mention on the flickr thread I feel that we need to get some initial requirements / specs tied down.

I also agree with many of the comments in that we should concentrate on getting basic functions working. So if we get a list of these functions and put them out on a poll so we can nail them down.

Then once we get these we can assign tasks/groups

Stephen...
seaton
Site Admin
 
Posts: 134
Joined: Mon Jan 23, 2006 8:48 am
Location: Bunbury, Western Australia

Postby ben-s » Thu Sep 20, 2007 4:03 pm

Hi Stephen,
Here's to the success of the project!

I think the link in the flickr thread is wrong, it goes to http://forums.everythingrobotics.com.au
I couldn't get through, so I deleted the .au bit, and it started working.
You might want to correct the flickr thread?

I think this has something to do with why I'm currently the only user... :)
Lens caps and cable releases can become invisible at will :D
ben-s
 
Posts: 5
Joined: Thu Sep 20, 2007 2:11 pm
Location: Nottingham, UK

requirements

Postby thenickboy » Fri Sep 21, 2007 5:49 am

I posted some mechanical requirements/wants in the mechanical area. but I think that was a bit premature - I think we should brainstorm here a bit.

Here's my wants:
-small form factor (similar or smaller size than PWs)
-prefer similar form factor (housings) with the xcvr units
-folding/telescoping antenna
-PC cable connectors (with covers)
-AA or replaceable re-chargeable batteries
-dark plastic housing
-recessed buttons
-recessed mechanical power switch or press-hold on-off switch
-metal hot-shoe (debatable, i see the need for plastic as well)
-easily accessible transmitter module to change for travelling to different countries (?) -diff countries, diff freqs

We need some of those good ideas from the flickr group to come over here!

Nick
thenickboy
 
Posts: 13
Joined: Fri Sep 21, 2007 1:07 am
Location: Matsuyama, Japan

Postby mattsteg » Fri Sep 21, 2007 5:55 am

I guess what I'd like to see (in order of what order I would implement them) is:

1)trigger a flash (and control its power). This is trivial and there are piles of schematics out there. 1a is to do so with a "smart" circuit (i.e. with a micro) rather than just a bunch of analog stuff. http://snowcat.de/flashcontroller/ appeals to me because it triggers with a micro and gives us electronic power control. This should pretty much plug right into any old-school TTL flash I think, and full-manual flashes could be hacked to cooperate too. Heck, with this sort of circuit you can really cheap out on the flash as you don't really need even manual control. Easy to add protection http://strobist.blogspot.com/2006/10/di ... rcuit.html for old, high voltage flashes too. Make these triggers right and we can really go for bargain-basement flashes (while outperforming the $$$ ones) Probably need to calibrate to individual flash durations though. It may make sense to dedicate these per-flash if that is the case and connect the wireless transport as needed.

2) trigger a flash based on a signal that we can transmit wirelessly without too much difficulty. (for example, a serial signal). We need to be able to talk to the chip and tell it to hit the lights. Using serial also makes it nice and easy to develop without having the wireless hardware (and leaves room for swapping of parts if needed or if desired for cost reasons)

3)Fire a single flash remotely Well, I suppose I should put wireless transport here (but it can go almost anywhere in the imo, as it's abstracted from the actual communications that fire things) I really like the looks of the XBee Pro. Lots of power and range, nice performance and features, ability to either talk to individual other devices or broadcast to a group. http://www.maxstream.net/products/xbee/ ... zigbee.php
Wireless connection is at 250kbps, and the maximum interface datarate is 115.2 Kbps. Let's say we run at half that, 56k. Say we use a 2-bit firing signal to prevent false triggers. 2bytes/56kbps is under 300 microseconds . We're at around 1/3500 s to transmit that signal, plus whatever processing time we incur. Normal triggering should be plenty fast enough.


4)Remote manual control of a single flash. Since we have a serial connection to the chip firing the flash and controlling its power, it's a matter of not-much-code to adjust the power setting manually over the serial link.

5)Do broadcast-firing of a semi-arbitrary number of strobes. Make sure that we can do this with the chosen wireless implementation. Potentially send a stream of firing commands at low sync speeds to overcome iffy communication. At high sync speeds probably better-off implementing a system where the receivers report firing.

6)remote manual control of multiple flashes, fire individually and in broadcast. This is mostly a case of adding functionality to the transmitter and probably adding an lcd, buttons, etc. so that we can do things and see what we are doing. A good interface design to make things powerful and magageable would be nice.

7)get some communication going from the receivers. When the receivers trigger their strobes, they report back that they did so. Just a nice little robustness feature so we know things are working. Maybe configure a mode where strobes receivers can act as repeaters to trigger more distant recievers. Basically add features and robustness.

8)consider TTL, quasi-TTL, etc. Multi-flash TTL is going to get really complicated really quick. Now we're in the realm of more polishing, software writing, reverse-engineering, etc. We're into writing significant vendor-specific code to. We're also significantly beyond wizards in a lot of ways. Reliable one-location manual control and firing of flashes at significant distances at a reasonable price is a pretty good place to reach. Anything more is a (potentially realizable) bonus imo.

The more I lay out these requirements, the easier they seem in a lot of ways. TTL and fancy stuff like that is going to be more involved, but to get something beyond PWs doesn't seem like too huge of a leap.
mattsteg
 
Posts: 26
Joined: Fri Sep 21, 2007 5:21 am

Postby seaton » Fri Sep 21, 2007 9:23 am

Doh! Sorry about that, been caught on the hop with this thing lol

ben-s wrote:Hi Stephen,
I think the link in the flickr thread is wrong, it goes to http://forums.everythingrobotics.com.au
I couldn't get through, so I deleted the .au bit, and it started working.
seaton
Site Admin
 
Posts: 134
Joined: Mon Jan 23, 2006 8:48 am
Location: Bunbury, Western Australia

Postby seaton » Fri Sep 21, 2007 10:06 am

mattsteg wrote:1)trigger a flash (and control its power). This is trivial and there are piles of schematics out there. 1a is to do so with a "smart" circuit (i.e. with a micro) rather than just a bunch of analog stuff. http://snowcat.de/flashcontroller/ appeals to me because it triggers with a micro and gives us electronic power control. This should pretty much plug right into any old-school TTL flash I think, and full-manual flashes could be hacked to cooperate too. Heck, with this sort of circuit you can really cheap out on the flash as you don't really need even manual control. Easy to add protection http://strobist.blogspot.com/2006/10/di ... rcuit.html for old, high voltage flashes too. Make these triggers right and we can really go for bargain-basement flashes (while outperforming the $$$ ones) Probably need to calibrate to individual flash durations though. It may make sense to dedicate these per-flash if that is the case and connect the wireless transport as needed.


This should be the easiest of the lot, really to trigger the flash we just need to short the centre hotshoe or PC Sync to ground, as for power control the strobe unit controls the flash power, and I guess this is where TTL/ETTL comes in via the other hotshoe contacts, my guess is the camera tells the flash via these contacts what setting it wants, i.e. zoom, f-stop and power. So this is where our units will need to eventually bridge the cameras protocol to the flashes, but this is for later on :)

All we need is something to handle the voltages of the older units (300V?)

Stephen....
seaton
Site Admin
 
Posts: 134
Joined: Mon Jan 23, 2006 8:48 am
Location: Bunbury, Western Australia

Postby Bluphoto7 » Fri Sep 21, 2007 10:31 am

I know ETTL uses two way comms, although the upstream and downstream paths are on different pins so that should make things easier. I also think it's only half duplex, so the devices are either receiving or transmitting, but not both at once.

If we are going to design a simple flash trigger, and then upgrade the SW to make it ttl comatible, then we nned to build in as much speed as we can, and at least allow for bidirectional comms, although V1 probbaly won't implement this function in SW.

Alternatively, we go for two models, the Strobist "Puppy" and the Strobist "Wolf".

On the mechanical side of things, this baby needs to be robust enough to survive in a box without much protection - I'm talking about the Pocket wizard type antenna, rather than the flimsy Skyport affair.

If we want a low profile transmitter, capable of going in a shirt pocket, then those external 2.5" hard drive enclosures would be ideal - made of machined aluminium. All we'd need to do would be modify one of the end caps to take the PC Sync skt and the Antenna. The also cost next to nothing - retail about GBP£5 each. If we need to go ttl, then we just screw a "hotfoot" to the bottom. If the board is small enough, then we can just cut the thing in half! Should also take AAA cells, I think.

As for component choice - we'd need this thing to work reliably at temperature, as well as in the cold. I'm talking -20C to+50C - maybe that means mil-spec components.

We build electronic sensors for the bottom of oil wells, and electronics don't tend to work the same way at 150C as they do at a nice room temperature. Capacitors are one of the worst offenders, so take care over your choice of caps.

Of course, all of this is beyond the prototype, but should be considered for the final spec list.

cheers,
Guy
Bluphoto7
 
Posts: 10
Joined: Fri Sep 21, 2007 9:57 am

Postby seaton » Fri Sep 21, 2007 10:51 am

I think the Requirements that someone has put up on the WIKI pretty well cover things as far as V1 goes, with a view of moving towards V2 with minimal hardware changes as well. Very achievable I think.

However I feel that we should try and build around a standard hardware platform that we can use for V2 i.e. all that may be different between V1 and V2 is the software. Soooo we may need to research possible processor requirements and candidates.

I really don't mind what we use here, as I'm willing to learn something new, however I am tooled up for PICS and the AT91SAM7X

If we can come up with a list of candidate processors I can put up a poll and we can vote on the V1 Core MPU. Ultimately I see this project being fairly open and modular, and if we standardise and document our protocol between the units then people can hack their own modules using processors of choice, but first steps first, I feel we standardise on one MPU and make this our reference design through all versions until a major requirement requires us to change down the track.

So in short one hardware platform that is sw upgradable, although not ruling out board mods along the way between revisions.

I see that once we get the hardware nailed down and out of the way we can concentrate on form factor/mechanical design, protocol design and software development that all can run parallel.

Stephen....
seaton
Site Admin
 
Posts: 134
Joined: Mon Jan 23, 2006 8:48 am
Location: Bunbury, Western Australia

Postby mattsteg » Fri Sep 21, 2007 1:29 pm

seaton wrote:
mattsteg wrote:1)trigger a flash (and control its power). This is trivial and there are piles of schematics out there. 1a is to do so with a "smart" circuit (i.e. with a micro) rather than just a bunch of analog stuff. http://snowcat.de/flashcontroller/ appeals to me because it triggers with a micro and gives us electronic power control. This should pretty much plug right into any old-school TTL flash I think, and full-manual flashes could be hacked to cooperate too. Heck, with this sort of circuit you can really cheap out on the flash as you don't really need even manual control. Easy to add protection http://strobist.blogspot.com/2006/10/di ... rcuit.html for old, high voltage flashes too. Make these triggers right and we can really go for bargain-basement flashes (while outperforming the $$$ ones) Probably need to calibrate to individual flash durations though. It may make sense to dedicate these per-flash if that is the case and connect the wireless transport as needed.


This should be the easiest of the lot, really to trigger the flash we just need to short the centre hotshoe or PC Sync to ground, as for power control the strobe unit controls the flash power, and I guess this is where TTL/ETTL comes in via the other hotshoe contacts, my guess is the camera tells the flash via these contacts what setting it wants, i.e. zoom, f-stop and power. So this is where our units will need to eventually bridge the cameras protocol to the flashes, but this is for later on :)

All we need is something to handle the voltages of the older units (300V?)

Stephen....
Gotta walk before we can crawl. In all honesty, given the proper parts, what I've laid out should really all be pretty easy to do (at least 1-7) I believe old-school TTL just gets a signal when to stop emitting - that's how the trigger I linked to works. In addition, any flash that adjusts its power in any way is going to have some sort of stop signal - the ones controlled by a resistor (either set manually or a photodiode) still quit firing upon a voltage reaching a certain level from what I understand (and that's how I'd do it), so for those flashes it should be pretty easy to retrofit a control circuit. ittl/ettl may be convenient, but imo that's really a second-gen product. You're starting to get gender-specific code that only works with pretty new flashes and adding a lot of complexity. Even if we do develop ettl code, for full compatability we'd need ittl and a more generic approach like I listed for non-ettl flashes.

As far as handling old, high-voltage flashes, that's no big deal. Lots of pre-tested isolation schematics out there.
mattsteg
 
Posts: 26
Joined: Fri Sep 21, 2007 5:21 am

Postby tim-j » Fri Sep 21, 2007 1:32 pm

Thanks for setting up this site.

I'm another whose main (only) requirements are

1) fire the flash (obviously!)
2) change the power of each flash remotely.

I really wouildn't be interested in acquiring anything more than what I've got already if it hasn't got (2), however much fun it could be to participate in this project.

Trouble is, you start getting into user-interface issues. Anyway, let's see which way things go. I'd love to hear what other people think about this -- i.e. changing the power remotely and what would conststute a good U.I.
Tim J.
tim-j
 
Posts: 6
Joined: Fri Sep 21, 2007 1:23 pm
Location: London, U.K.

Postby Bluphoto7 » Fri Sep 21, 2007 1:57 pm

So kind of a remote manual flash, rather than full TTL.

I'm not sure how we can find out how to control the power of a flash via the hotshoe.

I'm hoping that we aren't actually isolating those with new flashes which CAN talk E/I-TTL

How do we find out if is't possible to alter the flash power settings via the hotshoe WITHOUT actually communicating with the camera.

I would actually think it would be EASIER simply to pass the data from the camera through to the flash (and back) rather than coming up with the commands to emulate the camera from scratch in the transmitter - although I agree that this would be really nice.

It should be straightforward if there's just a fire...quench signal pair, but I think for the more advanced flashes, it might be more complex than that. I can see us needing to reverse engineer some of the more modern flashes to accomplish this.

For that matter, I don't know if its even POSSIBLE to remotely adjust the output power of my 580ExII from the camera, although I THINK I can remotely adjust the 430Ex from the 580Ex.

I realise that we have to include older, cheaper flashes here, but we also NEED to include the modern ones.

If we CAN adjust the power of the units individually, then simply four pots(sliders or knobs) on the top/back of the unit would be a better way than navigating through (labour intensive) menus on an (expensive) LCD.

I don't think many (if any) of us will use more than four slaves - two for foreground and two for background.

You could then switch any receiver to "local" control - with one "power" pot, or "remote" control, where the power level is retrieved from the master unit.

I'd say full down to 1/16th plus "off" would be enough - this could easiy just be marked 5-4-3-2-1-0 on each power pot.

I have to say I prefer this idea over implementing ETTL, but although it sounds simpler, it may actually be harder as I think the power output of most flash units is set ON the flash unit itself, and can't be set through the hotshoe (perhaps apart from the ones which talk to eachother, like ETTL etc). I don't think we should go down the road of asking people to open up their flashes just so we can access a power control circuit.

I'd love to be mistaken.
Bluphoto7
 
Posts: 10
Joined: Fri Sep 21, 2007 9:57 am

Postby thenickboy » Fri Sep 21, 2007 2:23 pm

Bluphoto7 wrote:
On the mechanical side of things, this baby needs to be robust enough to survive in a box without much protection - I'm talking about the Pocket wizard type antenna, rather than the flimsy Skyport affair.

<snip snip>

As for component choice - we'd need this thing to work reliably at temperature, as well as in the cold. I'm talking -20C to+50C - maybe that means mil-spec components.



I agree that they should be capable of being thrown around. I'm pretty hard on my equipment. However, I don't think that we need to be going mil-spec. Mil-spec requirements I think are even higher standards than what the nicest camera (D3 or Mark III) is going EVER going to see. Not only that, mil-spec is expensive. SOMEONE's gotta pay for all that qual and CYA over-design.

For the antenna - I'd be a big fan of a folding antenna. I really want something that folds in my bag or collapses. I like the GPS antenna sizes, I think the freq is all wrong to use one, but we could design something with a similar size and robustness that folds down.


If we want a low profile transmitter, capable of going in a shirt pocket, then those external 2.5" hard drive enclosures would be ideal - made of machined aluminium. All we'd need to do would be modify one of the end caps to take the PC Sync skt and the Antenna. The also cost next to nothing - retail about GBP£5 each. If we need to go ttl, then we just screw a "hotfoot" to the bottom. If the board is small enough, then we can just cut the thing in half! Should also take AAA cells, I think.



This is good for V1, but I think to make this thing marketable, we should be smaller than the PWs we're making to replace them. I can't imagine my portable HD on top of my camera - it's really cumbersome in addition to my vertical grip.

An aluminum housing would be good for thermal issues and shielding, but I'm worried about crushing or denting even scratching - those housings are not meant to be thrown around due to what's inside of them. Hard drives are delicate and you're supposed to treat them as such when you carry them.

Nick [/quote]
thenickboy
 
Posts: 13
Joined: Fri Sep 21, 2007 1:07 am
Location: Matsuyama, Japan

Postby tim-j » Fri Sep 21, 2007 2:29 pm

I'm afraid I don't know Canon flash units, as I've got Nikon gear :(

With the SB-800 & SB-600, the output can be set via the extra pins of the shoe. I guess it must be the same for any flash that you can put in the hot-shoe and then set the power from the camera.

The (SB-800/600) can also have the power output set remotely via optical signals, in which case it's done by about 4 low-intensity flashes that have carefully timed spaces between them, before the main burst.

How do we find out if is't possible to alter the flash power settings via the hotshoe WITHOUT actually communicating with the camera.


What I was envisaging is finding out what signals on the pins do to set the output power (e.g. by monitoring the signals while using the camera to change the power), and then implementing that. We'd need some kind of modular approach, to accommodate the different pin layouts and different flash units. Don't know how practical that is! Otherwise, communicate with the flash through the optical sensor :?:

Sorry for all the blue-sky hand-waving :roll:
Tim J.
tim-j
 
Posts: 6
Joined: Fri Sep 21, 2007 1:23 pm
Location: London, U.K.

Postby Elv000 » Fri Sep 21, 2007 3:13 pm

Canon doesn't have manual flash control for or from the on board camera flash. To trigger slaves you need a transmitter in the hotshoe (ST-E2) or use a flash on camer as the master 550/580EX.

Thats why it would be good to just convert the preflash light pulses (of any master) to radio and back at the flash. That way your not decoding any proprietory systems just passing the signal on! (just as Radiopopper.com claims to have done). So it works with any brand. Seems silly to do it any other way if it makes it more complicated?!

So many peolpe have previously come in and stated they know how to do this hopefully someone that does will still find this board?!

Does anyone actualy know if there actualy is two way communication???. Can anyone put a scope on an ITTL/ETTL slave and see if there is any irregular pre flahshes (sending info back to the master).
Someone posted something similar off a Pentax or other brand on the Strobist thread (on camera)
Elv000
 
Posts: 17
Joined: Fri Sep 21, 2007 3:40 am

Postby mattsteg » Fri Sep 21, 2007 3:14 pm

Bluphoto7 wrote:So kind of a remote manual flash, rather than full TTL.

I'm not sure how we can find out how to control the power of a flash via the hotshoe.
I've already linked to a schematic and code that can do that for any plain TTL flash (and should be easy to modify any controllable flash to work as well)!
Bluphoto7 wrote:I'm hoping that we aren't actually isolating those with new flashes which CAN talk E/I-TTL
It should be perfectly easy to implement things in a more generic manner (although it may require a bit of calibration)
Bluphoto7 wrote:How do we find out if is't possible to alter the flash power settings via the hotshoe WITHOUT actually communicating with the camera.
It is. That's how all those 20+ year old TTL flashes work. Once again, I linked to a circuit that does this job already.
Bluphoto7 wrote:I would actually think it would be EASIER simply to pass the data from the camera through to the flash (and back) rather than coming up with the commands to emulate the camera from scratch in the transmitter - although I agree that this would be really nice.
Passing commands can introduce latencies which make things not work.
Bluphoto7 wrote:It should be straightforward if there's just a fire...quench signal pair, but I think for the more advanced flashes, it might be more complex than that. I can see us needing to reverse engineer some of the more modern flashes to accomplish this.
Most of the newer flashes still have a fire/quench as far as I know. Nikon's still support straight TTL at least... It's only more advanced if you run in the more advanced modes.
Bluphoto7 wrote:For that matter, I don't know if its even POSSIBLE to remotely adjust the output power of my 580ExII from the camera, although I THINK I can remotely adjust the 430Ex from the 580Ex.
If your flash works in TTL, it's possible to adjust its power from the camera. After all, the lens is attached to the camera... Sure, there's not a "set this power" option, but the camera can certainly tell the flash to use a certain power in some fashion (at the very least fire/quench should be available, and that's all we need for pretty much infinite adjustability).
Bluphoto7 wrote:I realise that we have to include older, cheaper flashes here, but we also NEED to include the modern ones.
Most newer flashes have more capability than the older ones, not less. If cannon neuters their flashes I feel sorry for you, but I know my nikon stuff can run straight ttl...
Bluphoto7 wrote:If we CAN adjust the power of the units individually, then simply four pots(sliders or knobs) on the top/back of the unit would be a better way than navigating through (labour intensive) menus on an (expensive) LCD.
What if you want to adjust and trigger 5 strobes? I also prefer controls that are not easily bumped/broken (like sliders and knobs). LCD means you can go purely button driven plus display arbitrary information if needed. Small character LCDs aren't that pricy, and you only need one.
Bluphoto7 wrote:I don't think many (if any) of us will use more than four slaves - two for foreground and two for background.
No need to limit to it though.
Bluphoto7 wrote:You could then switch any receiver to "local" control - with one "power" pot, or "remote" control, where the power level is retrieved from the master unit.

I'd say full down to 1/16th plus "off" would be enough - this could easiy just be marked 5-4-3-2-1-0 on each power pot.
Imposing those sort of limits arbitrarily just seems silly to me. I'd also strongly prefer buttons over pots that can get bumped, broken, etc.
Bluphoto7 wrote:I have to say I prefer this idea over implementing ETTL, but although it sounds simpler, it may actually be harder as I think the power output of most flash units is set ON the flash unit itself, and can't be set through the hotshoe (perhaps apart from the ones which talk to eachother, like ETTL etc). I don't think we should go down the road of asking people to open up their flashes just so we can access a power control circuit.

I'd love to be mistaken.
Why the obsession with the proprietary ETTL interface? These aren't canon-only triggers... And once again, if a flash supports TTL manipulating power is easy and can be done pretty much arbitrarily. Whether you speak fire/quench ttl, ettl, or ittl, they all do the job.
mattsteg
 
Posts: 26
Joined: Fri Sep 21, 2007 5:21 am

Next

Return to Requirements

Who is online

Users browsing this forum: No registered users and 1 guest

cron