Paul C. Buff, Inc. Technical Forum

All,

I have been having trouble with my Einsteins randomly firing when the CXSCV are attached. I was using a CST on my Canon 5D MkII and adjusting with the CyberCommander. As the units heated up they seemed to fire more often. I did not remove the CXSCV to see if that would stop the issue or turn off the CST or even remove it from the camera. I will try both scenarios tonight. I was in the middle of a shoot and just soldiered on.

Has anyone else had this issue?

Robert

be sure to test with the slave eye off. this will tell you if it is isolated to one light or all lights.

also was the random fire one pop, or several?

I had a shoot this past weekend, assistant inadvertently turned the slave for one of the four Einsteins to On. I keep it turned off myself, all the time, since I had to call Customer Service whenI first got them, as I could not fire them individually with the CC. I was informed that, inexplicably, the slave is defaulted to On even when the CSXCVs are installed (!?!).

But, back to Saturday: we set up outdoors, with a low setting sun--but the sun still caused the Einstein to start rapid firing.

I consider this a defect in the design--I never had this issue with ABs, or any other light: I have had the sunlight interfere with the slave's ability to pick up a flash from another strobe, preventing a trigger, but having the Einstein start uncontrollably rapid firing is, frankly, bogus.

It seems to me that the slave functionality on the Einstein needs a rethink: it defaults to on even when receivers are connected (the ABs are 'smart' enough not to do that), and the sun sensitivity means they are impossible to use in slave mode outdoors (reliably, anyway). One is forced to use a trigger/receiver on each unit when out on location. I could understand if the slave might misfire if overwhelmed by the sun, fail to trigger--but to just start machine-gun firing is unacceptable behaviour.

Again, the sun was not directly overhead, it was low on the horizon (about 5-10 minutes before sunset).

Don't get me wrong--I LOVE my Einsteins, and would still recommend them. But these particular slave-related issues are flaws in my opinion, and are the only complaint I have about the otherwise superb product.

I have the v1s, due for a V2 replacement. I'd be happy to wait for a V2.1 that solves this problem, if it can't be fixed by firmware.

It would be a shame if we all had to put butt-ugly duct tape on our Einstein Slaves. It would kinda be like those little bandaid stickers for the iphone 4 antennas...

Just to clarify, only the light that the assistant switched the slave eye on rapid fired, correct?

What means were you using to trigger the lights?

Yes, only the light with the slave enabled started rapid firing. I was using CST and CSXCVs in all four Einsteins. I think it began rapid firing upon the first trigger for a test shot: in other words, the Einstein was not initially triggered by the sun/slave, but once the slave detected another flash, then the rapid firing started. Note that the rapid firing unit also had a CSXCV installed, so it would have also received a trigger signal from the CST.

I suspect that there could even be a feedback/time-delay issue that causes oscillation when the slave is enabled when a CSXCV is also triggering the unit, exacerbated by the sun on the slave sensor.

I have not experimented on this (don't want to overstress my Einstein) but an interesting experiment might be to take two Einsteins out in the sun, both with CSXCVs installed. Enable one slave, hit test on the CST. Verify rapid firing can be duplicated. Then cover the slave sensor, but leave it enabled, see if the rapid firing can be replicated. Uncover the slave sensor, remove the trigger, hit the CST, see if it still happens.

If the rapid firing only happens when both the slave and CSXCV are active, then a firmware change to force slave to disable when the CSXCV is installed should solve the problem.

If the rapid firing still occurs with CSXCV removed, then it is more likely a sensor sensitivity/gain/hysteresis sort of issue.

But I would REALLY like to hear the reasoning for the design decision that even allows the slave to be enabled when a CSXCV is in place.... Is there any scenario where I would want them both active? I can't think of one. And I can foresee a number of bad things happening when they are........

The only time we have been able to reproduce this is if the Einstein is in direct sun, the slave eye is on and if connected to a Vagabond. This does not happen (in our observations or any customer conversation I am aware of as of yet) if the Einstein is connected to AC mains power or in the shade. What does happen is the E640 does not fire until the initial pop of the flash unit, then it can rapid fire. Presumably, this is a by-product of the nature of recycling off of a Vagabond. We will be testing the new versions next week.

Ah, okay, I neglected to mention that I was also using a vagabond.

Is there any plan to fix the firmware so that an installed CSXCV will automatically disable the slave? There seems to be no good reason to allow the slave to be on when using a trigger/receiver.....

Is the vagabond influence also present (rapid firing) when using slave only, no CSXCV installed? i.e we simply cannot use the vagabond/slave/sunlight option at all?

I dont recall off hand if we tested all CSXCV in/out combinations, but i doubt it would have much to do with it. I am not aware of any firmware adjustments at the moment, but we will be testing the new versions to see if it is even a problem on those first.

No need to mention it was on a Vagabond. Vagabond and sunlight often go hand in hand, so its a pretty safe bet 8-)

Independent of the random fire issues, having the slave default to on (even though you can change it) is odd, but allowing the einstein to enable (or keep enabled) the slave when a csxcv is installed is just a design flaw. When would we ever want to have the slave on when using the csxcv?

You have had a number of questions on this forum because nobody expects to have to deal with this odd quirk, and it is especially confusing for new einstein and cyber commander owners trying to figure out why they can't remotely trigger individual einsteins from the CC.

We are then asking here, or calling customer service (as I had to) only to be amazed that even though I had the receivers installed, ALL my lights were defaulted to slave enabled, and all would fire when I triggered just one from the CC.

So even if the rapid fire thing is completely resolved, there is still a firmware fix needed so that the Einstein recognizes the CSXCV and AUTOMATICALLY disables the slave.

If you want to leave in the option for slave to be enabled even when the CSXCV is installed for some remote corner case (user wants to use slave mode, but wants to keep the CSXCV 'stowed' on the Einstein) then that should be fine, I guess.

But I have four einsteins, four CSXCVs, two CSTs and a CC. I don't ever want to be hassling with the dang slave settings unless I have a deliberate and specific need to do so. It should default to disabled when receivers are in place.

So I consider the rapid firing to be a glitch situation that you will resolve. But I consider the slave not defaulting to off when CSXCVs are installed to be a fundamental design flaw (and the only such fundamental flaw I have encountered--not counting the heat issue workaround while waiting for V2).

I really think this should be corrected in a firmware update.

Just to add to the mix, I was not using a Vagabond and was shooting indoors. The walls are white and there was an overhead light on. I did also have the beauty dish in place on one light and a large gold umbrella on the other.

I agree that the slave eye being on when a CSXCV is connected is redundant and potentially in conflict.

Robert