A few years ago I bought two Yongnuo RF-602 RX receivers and a Yongnuo RF-600 TX transmitter for my Canon flash units. Recently they started misbehaving. Sometimes the flash didn’t fire, sometimes it fired to late. When using the test button however, the transmitter worked fine. What I noticed was that the green light on the front of the transmitter was flashing more or less continuously (when connected to a camera and the camera was on).
The green light is supposed to light up when the shutter button is half-pressed, and I assume it sends a signal to the receivers to wake up the flash. I also suspect that this behaviour, where the green light is on for no apparent reason, is “jamming” the other signal.
If you have this problem, the easiest way to verify is to block all the pins on the hot shoe except the one in the middle, which is transmitting the trigger signal. I used a thin piece of plastic to test this. This silenced the false signal and allowed the real trigger signal to function.
The more permanent solution is to open up the RF-600TX and remove the wiring to the offending pin. The unit has 3 wires. One for the trigger signal, in my case the wire in the middle, one wire for the base of the hot shoe, let us call it ground, and a third wire going to one of the other pins. This will vary depending if you have the Canon or the Nikon model.
Figure out which wire goes to the center pin, and which goes to the ground. Cut the third wire. Or take a soldering iron and gently remove it, in case you want to reattach it. That is what I did. To figure out what’s what I used a multimeter.
By the way, this might slow down the sync speed. But in my case it never worked with anything higher then 1/160 anyways…
Update: I just thought about this. To wake up the flash unit(s) you can half-press the test button instead of the shutter button. Or just force the flash units from going into sleep mode.
Sunday 22th of September the disk in my server failed, and years and years of unique data dissapared with it. Projects, websites, bits and bytes. All gone. The only piece I did have backup of was the databases from MySQL, and those were 6 weeks old at the time.
Thanks to my (irregular) backup of the SQL databases, this blog is now back online. I have re-uploaded some of the blog images from other sources, and over time I hope to reconstruct (most) of the rest.
Conclusion: Shit happens. Be prepared.
Update: Found backup of the home directories and web directory from june 2010. Only 3 years of files missing. Oh, and the subversion repository.
Update 2: All visible images on this blog have been replaced. Yay!
Just realized how fragile a virtual machine can be.
Yesterday I logged into a Windows server and found that some programs were missing (python among others). No big deal. I just assumed that someone else had removed them to free up space or something. Then I found a few files I knew I had both edited and deleted. And the files I knew I had touched suddenly had a timestamp dating back to 2008. Luckily this isn’t a critical production machine, but never the less, how could this happen?
When I checked the vCenter log, I found that the virtual hardware on this particular VM was updated just short of 24 hours earlier. The VM also contained a system generated snapshot dated 2008. The Windows event log, however, where having a gap from 2010 till 2012 (current day).
What has happened is this:
• The VM was powered off.
• The virtual hardware was upgraded.
• When the machine was turned back on, the system reverted back to a previous snapshot (without logging it), thus overwriting the current image.
There are several things here that I find “scary”. The first is that the VM went back using an older system state without even logging it.
The second “scary” thing is that the system generated snapshot was wrongly labeled with the year 2008, when it clearly contained data from 2010 (We actually tested this by reverting to this image just to check. We had nothing to loose anyway).