Direct communication between the PC and the FIRST Ren-W is likely best at 57600, M,8,2. After that, communication in a wireless daisy-chain must be at 57600,N, 8, 1 because Renard strips the parity and space bits out of the data. In fact, this happens with the very first PIC the data gets to -- any data flowing to the next PIC no longer has the parity and extra stop bit. The parity and extra stop bit serve to slow down the Xbee radio just a bit because the XBee's internal CPU/clock runs slightly hot -- a little bit faster than 57600 which is the exact speed the 16F688's are running. The dropped data at the 8th consecutive pic is actually a data overrun problem.
I have confirmed that wireless to two ss24's is okay at 57600, N, 8, 1, but the third SS24 in the chain will encounter the problem at channels 57-64. The problem with daisy-chaining wirelessly is that there's no way to reset the communication protocol to 57600, M, 8, 2 when the data comes out of the SS24 (or any Renard controller for that matter) and goes into the Ren-W. So setting a daisy-chaining XBee to use the M,8,2 parameter will cause communication problems between the SS24 and the Ren-W resulting in garbage data for the rest of the daisy-chain.
The solution is not to try to daisy-chain to a one or a set of controllers having more than 56 contiguous channels. In that case, using 57600, N,8,1 is perfectly fine. Daisy-chaining from an SS24 to another SS24 is fine; daisy-chaining from one SS24 to TWO more ss24's in a row is fine. But daisy-chaining to 3 SS24s in a row will not.
Confused? Just think about it a bit... it will come to you...