Transparent mode may mean one of two things:
- Especially on some older devices, it may mean that the data presented to one device will be sent over the air, bit for bit, exactly as presented; the other device will output electrically, bit for bit, exactly what it receives over the air. There's no guarantee that the receiver won't electrically interpret random noise as data when the transmitter is idle, nor is there any guarantee that data which is transmitted will be received correctly. The one thing which is guaranteed is that if a receiver is going to receive correct data, it will do so within a very short time of its being transmitted. On the other hand, it is possible for the microcontrollers which are connected to such devices to supply their own logic to determine when data is received correctly as sent, and arrange for whatever retransmission strategies are appropriate for a given application.
- On some devices, including some newer modules, it means that a transmitter will make a best-effort attempt at delivering arbitrary sequences of bytes, without requiring the controller which supplies the data to wrap it in any sort of packet. The module will automatically take groups of bytes, wrap them in its own packet format including things like sequence numbers, checksums, etc., and then transmit them, listen for acknowledgment, and possibly retransmit them a few times if needed. In most cases, the alternative is for an application to format packets of data in a specified way for transmission, and for the receiving device to supply the packets in that format.
I've used devices with both types of transparent mode, and I've also used packet mode. The first type of transparent mode can be a bit tricky to work with, since modules that provide it don't usually guarantee much of anything other than the fact that any data which will be transmitted successfully will be transmitted immediately.
I really don't like the second type of transparent mode. In a lot of ways, it's like a radio version of the TCP protocol used on the Internet, with the automatic grouping of data into packets, along with the automatic error-detection and retransmission logic, but there's a critical difference. TCP offers a 99.99999% guarantee that if a device establishes a connection and asks to transmit a sequence of bytes, either the recipient will receive all of the data in sequence, or the sender will be notified that the connection was broken; it further guarantees that while a broken connection may prevent a receiver from receiving all the data sent by the transmitter, the first N bytes fetched by a receiver after establishing a connection will always be the first N bytes sent by the transmitter. These guarantees apply regardless of the reliability (or lack thereof) of the underlying communications medium. By contrast, wireless modules in transparent mode generally do not offer any means of starting and stopping logical connections, nor do they offer any indication whether or when data was actually transmitted successfully, nor whether the sequence of bytes reported from a receiver represents the complete sequence of bytes produced by the transmitter, with no omissions. When communications conditions are good, transparent mode can work fine, but it really offers no useful guarantees sufficient to create a workable protocol. Even if one receives what looks like a packet from the transmitting application, there's no guarantee that it doesn't represent half of one packet whose second half was lost, combined with the second half of a different packet whose first half was lost. Further, it's very difficult for an application to apply any useful sort of retry logic on this type of transparent connection, since there's no way it can distinguish between data which has not yet been successfully transmitted, but which the module is planning to retry, and data which the module has given up on transmitting. If a module has given up trying to send something, it may be useful for the application to try again. On the other hand, application re-sends something before the module has given up, retransmission requests can pile up in the queue, causing the module to waste time sending those over the air even if the original request had finally completed successfully and the retransmissions were superfluous.
In many cases, I would suggest using packet mode. Packet mode usually guarantees that packets will always be delivered as a unit; if unit 1234 says a packet that came from 5678 with data "ABCD", then it can safely assume that sometime during the history of the universe, unit 5678 was asked to send a packet to it with a payload containing exactly four characters in the exact sequence "ABCD". The module might not guarantee much of anything regarding the timeliness of transmission, or whether packets will always be received in the order sent, or that a message which is sent once will only be received once, but such issues may if necessary be handled within an application by including sequence numbers within the data payload. Further, in packet mode--unlike transparent mode--most modules will notify a transmitter when they give up on trying to send something, allowing the transmitter to behave much more intelligently than would be possible in transparent mode.