Implications of short burst transmissions in radio? (SDR/gnu-radio)
We are unable to reliably transmit single packets

Yeah, me either.
If you can find any wireless protocol anywhere that never drops a packet, please let us know.

I'm guessing that you're working pretty "close to the metal" with this SDR, running simple experiments rather than using some tried-and-tested protocol. Here are a bunch of things that I often see go wrong. Perhaps if you're lucky you're only seeing one of these problems, and it's one of the easier-to-fix problems. Pretty much everyone building a wireless protocol from scratch bangs into several of these problems.


Perhaps bit-slicer is incorrectly slicing bits. The simplest on-off protocols need to discriminate between "on" and "off". Most bit-slicers assume that a simple leaky average of the signal over the past N bits is approximately halfway between "on" and "off" and makes a good reference point. Halfway through a packet, that's a pretty good assumption. When you haven't transmitted anything for a few seconds, you need to transmit some dummy data -- a preamble -- with a good balance of 1 and 0 bits (often 01010101 "UUUU" in the simplest protocols). That data in the preamble will be incorrectly received, but it pushes the reference of the bit-slicer to a point where the important data in the packet can be sliced properly.
Perhaps the gain the the AGC is not set correctly. With ASK or more complex IQ modulation, the gain in the AGC needs to be set properly to decode symbols properly. If you haven't transmitted anything for a few seconds, the AGC cranks the gain all the way up, and most symbols (except the maximum-amplitude symbols) will be received incorrectly. Again, dummy data -- a preamble -- to push the gain of the AGC to a point where the important data in the packet can be decoded properly.
Perhaps the center frequency is not exactly right, or the I and Q phases are "rotated". There are ways to detect and compensate for this -- typically using the known patterns near the end of the preamble.
Perhaps the symbol/bit timing is a fraction of a symbol/bit off. For very short packets, one of the 7 known Barker codes is useful for re-aligning the bit timing.
Perhaps your bit timing is good, but your byte alignment is off by some integer number of bits. Many people use 10 bits -- a start bit, 8 data bits, and a stop bit -- even on synchronous communication systems, because it makes debugging and byte-alignment ever so much easier.
Perhaps your bit and byte alignment is fine, but the packet framing is off -- the software is picking up some random bytes in the middle of a packet, an interpreting them as the "destination" and "length" fields of the packet header. Some people reserve the "newline character" for the start-of-packet character (the last byte in the preamble, or the first byte of the packet header, depending on your point of view), and forbid that character from ever occurring inside the packet, in order to make it easier to properly frame each packet, and debug when things go wrong.


All of the above issues occur even when there is practically no external noise.
With the above issues, if you send a packet enough times, sometimes the packet will happen to line up and get through just fine.

If you occasionally get a little noise, there are simple techniques to work around it: CRC, acknowledgment, retry-on-timeout.
In cases where I accidentally unplugged the antenna, or I rebooted the receiver, the transmitter may re-try transmitting the same packet hundreds of times before it gets a good acknowledgment in return.

If you get a lot of noise, there are terribly complicated techniques to work around it -- trellis coded modulation, iterative Viterbi decoding, forward error correction, frequency-hopping, noise detection and avoidance, etc.

Serial Programming/Forming Data Packets