There are a couple of things to keep in mind when considering the payload size.
The first thing to consider is that there is overhead associated with each packet. Exactly how much varies with a number of the configuration options available with WirelessUSB. Once these options are selected, you can expect the overhead to be consistent regardless of the size of the packet. Therefore, it is generally more efficient to transfer larger packets.
The next thing to consider is the impact of bit error rate (BER). In a given environment with a fixed set of configuration options there is a probability that any given bit may be corrupted when it is transmitted. At the lowest level is the probability of a DSSS chip being corrupted. The tolerance thresholds manage this to some extent, but with a set number of chips making up each bit you can still calculate a theoretical probability of an actual data bit being corrupted. This probability is the same for every bit; therefore, the more bits that are sent the greater the probability that any error occurs in the packet.
WirelessUSB LP does employ a CRC mechanism to help detect errors, but there is no a built-in error correction capability. Although error correction could be added in software, there may also be a packet size penalty to pay for that. For the moment, only consider that if an error occurs, it is necessary to retry sending the packet again if accurate delivery of data is essential.
Thus, there is a conflict. Larger packets are more efficient, but they may also be subject to a higher probability of failure and require retransmission, therefore increasing overhead in another way. Finding the critical point where the balance shifts one way or the other may require experimentation under the conditions required for the application.
There is one final consideration when dealing with larger packet sizes. Keep in mind that WirelessUSB LP has a 16 byte data buffer. This is significant particularly for battery powered devices that need to minimize power. For packet lengths up to 16 bytes it is possible to sleep the microcontroller after the packet is initiated because the radio’s Auto Transaction Sequencer (ATS) can manage the transmission without microcontroller intervention. For packets lager than 16 bytes it is necessary for the microcontroller to be awake at least periodically to manage buffer over- or under-flow conditions. Therefore, it might be beneficial to break large packets into chunks less than or equal to 16 bytes