Implications of short burst transmissions in radio? (SDR/gnu-radio)

Question

First of all, I do not have an electronics background. I have recently been experimenting with software radio using GNU Radio and a USRP1. I came here in hopes that some people outside of GNU Radio could lend some insight into my problem. I am not sure if I'll get any answers from here, but it's worth a shot.

---

We are experimenting with tunnelling a known communications protocol inside our GNU Radio transmissions. Within GNU Radio's modulators a packet_encoder class takes the incoming data stream, divides it into packets, and then sends it along to the modulator. The modulated data is then sent to the USRP for transmission.

Our problems seem to revolve around very short burst transmissions. For example, we are trying to perform a sort of hand-shaking process where one radio transmits a 'hello' packet and waits for a response. We are unable to reliably transmit single packets, but it seems we can get some throughput if we spam the same packet a few hundred times. Similar setups which continuously stream data from an input file seem to work fine in the same setup.

We have two USRP1 devices with suitable antennas located in the same room. As I have said continuous transmissions seem to work ok, but very short burst transmissions are a problem and we are not able to successfully transmit.

SO, my question is what are the various implications/issues surrounding short burst transmissions in radio? I am having a hard time finding the problem on the software side of things, and was curious if some insight into the hardware could help me. For example, are issues like this common in 'cheap' hardware like the USRP1?

http://en.wikipedia.org/wiki/Universal_Software_Radio_Peripheral

Thanks for looking!

Answer 1

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

Answer 2

This may seem silly but have you tried using an existing documented 'tried-and-tested' protocol first? There are various transmission methods and protocols already in use that would at least prove the hardware side is behaving correctly. Once you have an operable link with an existing protocol at your chosen frequency/bandwidth then you know the hardware is not your problem. From this point onward You can effectively measure the results of each change made in your new software. Remember to carefully document EVERY change you make before changing anything else! Ok I know it sounds boring but can be incredibly useful to reference back to changes made earlier in development. (No matter how hard You try, You won`t remember every detail later when You need it! Over the years I have often found old development docs have been handy when working on new projects.) When setting up data links we have found that it is very handy to have a third independent system monitoring transmissions so you can 'see' your signals. A nice spectrum analyser certainly helps but not everyone has one handy, Even a simple receiver or scanner can provide useful audible feedback. Extending preamble length has also proved very useful during setup/debugging, with it being reduced again for general operation once the link is up.

Answer 3

Interesting that you are having this problem. My lab mate is working with a GNU radio (USRP1) right now and found that very short packets tended to be all garbage. He was able to narrow it down to a couple things, but ultimately hasn't figured out why it is happening and is just focusing on longer packets now.

1st off, every time the radios start a broadcast, the receiver has to re-sync itself with the transmitter. Usually there is a preamble on the packet that allows for this to happen, but there is a chance that the radios aren't able to get a full sync on very short packets.

2nd, he was pulling all of his data from a file. He believed the system may have started to transmit before getting the data out of the file and the setup time for a harddrive to retrieve the file caused some "jitter" on the transmission.

Answer 4

If the packet gets eventually through, it means that you have some interference issue. Some possibilities, based on assumption that your continuous transfers are not actually all that continuous (droping data, as you indicate):

1) Strong source of interference on the same frequency you are using for transmission. This can be resolved by moving to another frequency.

2) Mismatched antenna. In this case the antenna can't pass enough of the received signal into USRP (or from USRP). Needs better antenna design or better matching.

3) Not receiving enough signal. In this case the signal will be burried in the noise. Can be resolved using more power on the transmitting side.

4) Not enough filtering on receiving side. Signal can be swamped by other signals received by the antenna, even if they are on other frequencies. Signal to noise/interference ratio can be increased by filtering the signal through bandpass filter that will select the signal and suppress the other signals you are not interested in. Ideally such filter will be placed between the antenna and USRP. Like in 2) the filter has to be impedance matched to the antenna on one side, and to the USRP on the other side. Another, narrowband filter should be used on the software side to further narrow down the selection.

That you are transmitting in bursts plays no role - unless you are having some timing issue with switching between transmission and receiving. The quality of USRP hardware also should not be an issue.

You can try experimenting with 1) and 3), and if it does not work, than you will need somebody with backgroung in RF design to do 2) or 4) for you.

UPDATE:

Given Kellenjb's friend analysis, this really looks like a problem with GNU Radio software. Look at what other possibilities it gives you both on transmit and receive, and try to use other modulations, methods of feeding it the data and so on to go around the issue. Another possibility is to debug the software.