Data transmission protocol brainstorm?

Software Design Discussions

Moderators: seaton, strogg

Data transmission protocol brainstorm?

Postby TwoLeftFeet » Sun Sep 23, 2007 7:07 am

Should a data transmission protocol be discussed in the software area?

After the first stage of a reliable wireless link is established, there will be a need to convert from Nikon/Canon TTL signals/protocols on the camera to a generic data protocol that will get unconverted back on the flash side. That generic data protocol will transmit all the information that the TTL would have transmitted over to the remote flashes.

A data transmission protocol should be something that is easy to implement, and something that has either headroom built-in, or can be expanded easily to accomodate unforeseen needs.

We can think about for example, header packets that tell the system how many packets are coming after and the purpose of those packets. Or we can do a system where we encode information into a standard sized packet, and have fields in there that let you know whether that it is the last packet. There are lots of options here. What kinds of checksums should we use (simple or complex)?

Some thoughts of a man at 2am... Hopefully they are coherent.
Posts: 12
Joined: Sun Sep 23, 2007 5:52 am
Location: Toronto, ON

Postby bintonav » Sun Sep 30, 2007 7:20 am

Yeah, the project would probably have to eventually deal with the complexity of ttl communication. But before reaching that point, would have to progress step-by-step from something as simple as reliably sending a signal from a transmitter to a receiver. Simple in the sense of being conceptually simple but complex in implementation from what I have gleaned by reading other's thoughts on the hardware side of the project.

Without initially dealing with the details of hardware implementation, the conceptual phases would probably be:

1. Phase 1. Reliably send data from transmitter to receiver.

This itself, alone, opens up a can of worms.

-What is the method of transport? Seems to be RF by consensus. But could also be optical.

-What is the maximum distance of receiver from transmitter?

-What kind of transport reliability do we need? Do we need 100% reliability such that everytime the transmitter sends a signal, the receiver must get it? Or is 95%, 90%, etc. reliability enough? There would be a tradeoff between reliability, cost, transmitter to receiver distance, and the time constraint with which the signal must get to the receiver.

-What protocol should we use? Should it be an off the shelf protocol or something new we invent?

The time constraint would probably preclude command/response protocol especially for the succeeding project phases where we would send more commands to the receiver.

Meaning, do we just send a series of commands to the receiver and leave it at that hoping that receiver receives data without error?

This would probably be the course of action, snce if there is an error, there is not enough time for the receiver to send an error reply and for the transmitter to resend the message (at least this is the assumption that I have at this point in time. If not true, well and good - means there is more flexibility).

Once we have the transport and protocol pinned down and testing shows that the flash fires 99% (is this acceptable?) of the time, then we proceed to the next phase.

2 Phase 2. Send same data to multiple receivers.

- Would probably be implemented by using some addressing scheme in the protocol.

2. Phase 3. Control power of the flash.

- This would probably entail a receiver unit calibrated to the flash brand/model (Canon, Nikon, Oly, etc) that it is connected to.

- Receiver controls flash output by controlling the flash duration which it does by outputting the quench signal at the appropriate time.

- Transmitter sends output power desired. Receiver looks up corresponding time duration, and loads downcounter with corresponding data. Receiver gets the trigger, turns on the flash, downcounts downcounter. When downcounter reaches zero, outputs pulse to quench pin of flash.

- Sending commands to control flash power is not time constrained since this can be done at anytime prior to using the flash.

3. Phase 4. Implement TTL protocol.

- This is probably the most complex of which I know nothing about and so will leave for others to contribute their piece.
Posts: 3
Joined: Sun Sep 30, 2007 5:18 am
Location: California

Postby MQ » Sun Sep 30, 2007 9:14 am

bintonav wrote:-What is the method of transport? Seems to be RF by
consensus. But could also be optical.

The initial unreliability of optical slaves is what drove most of
us towards RF devices.

Also, optical would only work in very simple plain sight
conditions. as soon as you start to create very sophisticated
light, you are likely to use gobos, flags and hide your
flashes behind $object. The flashes will not see each other
and either won't fire or can't be properly controlled.

So for this project optical transmission is no option.
If you are not part of the solution,
you are part of the problem.
Posts: 26
Joined: Sun Sep 23, 2007 8:32 am
Location: Germany

Postby bintonav » Sun Sep 30, 2007 4:52 pm

I included optical as one of the items in our menu of choices.

Another choice I forgot to mention is wire transport.

So we have three choices: RF, optical, wire.

We're choosing RF because of the unreliability of optical and the inconvenience of wire.
Posts: 3
Joined: Sun Sep 30, 2007 5:18 am
Location: California

Return to Software

Who is online

Users browsing this forum: No registered users and 1 guest