Canon 600EX II-RT drops link- HELP!

[Phillyphoto]

Scenarios I have tried: 

Using Canon Transmitter ST-E3-RT as the master and (2) 600 EX II-RTs as slaves.

Using A 600EX as master and B 600EX as slave.

Using B 600EX as master and A 600EX as slave. 

I get the same result of the slave dropping link. The time varies. Sometimes it drops link in 4 mins, sometimes 10mins, sometimes 20 or more minutes. The only way to relink them is by turning everything off and back on.

All channels are the same. Yes, I have scanned for the best connection as well as every other channel and AUTO.

All IDs are the same. 

Not near a wifi-router or airport, I'm in a row home in Philadelphia. 

Using NiMh rechargeables and using freshly charged batteries for every test. Batteries are about 2 years old. 

I have spoken to 2 Canon service reps and neither of them has any idea what the problem is. I really don't have the money to spend on sending everything in for "repair". 

Any help is greatly appreciated, thanks!

[crlyhds]

I can find nothing about noise flash sleeve anywhere. Can you provide a link?

[halocastle]

[Commercial link removed per forum guidelines and replaced with screenshot to facilitate discussion.]

[Steppy]

Pocket Wizard make (or made) 2 versions. The AC5 is effectively a sock which covers the entire flash, including controls.
The AC7 is a hard shell that I haven't seen until today. It would appear to be open at the back but would appear to only allow the flash to be used in the "straight up position". This would probably ok for most purposes if using stands. However, the rigid shell of the AC7 might not be compatible with the form factor of the 600RT series flashes - this would need to be verified.

Bear in mind that they were intended to reduce interference from the flash unit. They are RF shields. Blocking RF leaving or entering the flash is likely to reduce the range or may even completely prevent the communication. If you want to try this idea I'd just start by trying it on just one flash first, before investing on a complete set.

[Mannies17]

Got my AC5 sock in today. Testing tomorrow!

[Steppy]

The number of IDs is irrelevant. They are almost certainly just numbers transmitted as part of the message to identify which master and slaves belong together in one set. I'm working on a device to connect existing 2.4GHz system which uses a 4 byte ID in the same way. The value 9999 would probably be transmitted as 270F hex and reducing the number of IDs would simply reduce the size of the message by 1 or 2 bytes. This would have no effect on performance or the reliability of the connection.

As you mentioned in a previous post Canon provides 15 channels whereas the 2.4GHz WiFi band doesn't allow this number of frequencies anywhere in the world. The system I mentioned above also provides 15 channels but these are closer together than the WiFi channels. This is not actually very relevant because the bandwidth of the channels is actually wider than their separation so they overlap anyway. Incidentally, the IDs of the system I'm working on are not number in order of their frequency but appear to be completely random - or at least I can't identify any logic to their order. I think we can assume that Canon has not used the same channel separations as for WiFi and the channel numbers are probably not comparable, if not even completely different.

[halocastle]

I don't believe the number of IDs is, "irrelevant."  Strong RF interference can corrupt these values and large ranges have less tolerance.

This is why you must toggle radio to fix the issue.  Otherwise, I could just change the ID by one then back again and it'd re-link (or the channel).  It doesn't -- a drop is FUBAR.  And using ID 9999 -- the top of the range -- (and channel 15) has fixed my drops entirely (fingers crossed).

All of this is rather moot, as I provided before (emphasis is mine):

Part 15 of the FCC Rules...(2) this device must accept any interference received, including interference that may cause undesired operation.

[Steppy]

You are of course free to believe what you wish 😉
The FCC rule you quoted simply describes good design practice for any interface. This is almost certainly what Canon fully intended, but it would appear that they have simply failed in some way. Yongnuo and Phoenix have managed to do a better job. It's very similar to a camera firmware issue except we cannot simply download and install a new firmware version (in contrast to the Yongnuo flashes!).

[halocastle]

I hadn't planned on ego wrestling today...

Having completed yet another two hour test with my four 430EX III-RTs & ST-E3-RT (v1) -- all on channel 15 and ID 9999 -- without a SINGLE drop, I KNOW the following:

1) Canon RT IDs are HIGHLY relevant, 2) FCC rules are not "practices" but rules, and 3) Yongnuo (i.e. Canon RT) -- having owned them -- is garbage!

If anyone wants to bail on Canon, go Adorama/Flashpoint (aka Godox) and enjoy their customer service (I've read that Godox CS isn't so great).  Again, there is no Panacea.

P.S. Good luck on your device!

[Steppy]

1) This is already implemented but appears to be broken. As holocastle mentions this does indeed work correctly if the link is lost when the RF signal is temporarily lost due to range issues. As soon as the slave loses the connection it immediately attempts to restore the connection (without delay). This is standard implementation for a wide range of connection types. Unfortunately, in the case we appear to be discussing here, and the issue I have indoors, both the master and slaves get screwed up and lock up completely. This reconnection system no longer works. This could be due to either a hardware issue, or more likely a firmware issue.

[adelong]

I am having the exact same issue. They were reliable and now they are useless to me. How would I update the firmware in the flashes. I don't want to send them in, have them gone forever, pay crazy amount just to get a factory reset on return. Does canon not respond to these threads?