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?


Thanks for looking!

  • 1
    \$\begingroup\$ When you say that continuous transmission seem to work, what does it mean exactly? Are you receiving all data, or are there some retransmissions etc? \$\endgroup\$ Mar 28, 2011 at 14:40
  • \$\begingroup\$ Well, we definitely transmit data. We haven't implemented any packet synchronization yet, so I am unsure about how much data we drop during 'continuous' transmissions. However, I am quite sure that it drops data. Having said that, I need to look into other wireless protocols, because as you suggested no matter what I am going to drop data. I guess my problem is how to handle this with burst transmissions. \$\endgroup\$ Mar 28, 2011 at 14:48
  • \$\begingroup\$ What frequency and modulation type are you using? \$\endgroup\$
    – Kellenjb
    Mar 28, 2011 at 15:15
  • \$\begingroup\$ I checked with my lab mate, he wanted to know if you were using the built in mod and demod blocks as they are the ones that handle syncing. He also suggested to turn down your bit rate as the USB can provide some latency that causes jitter that is fine when you are able to buffer a longer packet, but with a short message doesn't work so well. \$\endgroup\$
    – Kellenjb
    Mar 28, 2011 at 18:54

4 Answers 4


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


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.


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.

  • \$\begingroup\$ It's a possibility, but wouldn't it render whole GNU Radio software completely worthless for digital communications? I mean, handshakes are pretty common ... \$\endgroup\$ Mar 28, 2011 at 15:08
  • \$\begingroup\$ Software radios are no where near prime time ready, doesn't mean they aren't worth the research that is going into getting them implemented. \$\endgroup\$
    – Kellenjb
    Mar 28, 2011 at 15:18
  • \$\begingroup\$ I get that, but this is rather basic thing and USRP hardware is not exactly cheap, so if this is really software issue, as your's friend data indicate, then I am still surprised ;) Hams, military, cell phone operators etc. all have SDR software and hardware that is definitely high quality and prime time ready, which is why I have not considered the possibility - that's not to say that you are not right. \$\endgroup\$ Mar 28, 2011 at 15:27
  • \$\begingroup\$ @Jaroslav Cmunt These radios are run over USB which provide some latency and jitter that wouldn't be an issue when implementing SDR in a portable device. \$\endgroup\$
    – Kellenjb
    Mar 28, 2011 at 18:55
  • \$\begingroup\$ That really should not be an issue, for example FLEX-1500, Open HPSDR and others also use USB. Open HPSDR even uses the same interface (Cypress EZ-USB FX2) as USRP1 and has the same overall architecture. The data are surely buffered, not just fed directly to FPGA and transmitted immediately, that just would not work. The latency also can't be an issue, otherwise continuous transmissions wouldn't work too. There is a way to debug it: capture the raw data that are being transmitted and analyze them. \$\endgroup\$ Mar 28, 2011 at 19:14

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.


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.

  • \$\begingroup\$ My guess is it is not a noise issue. My lab mate is doing research on bit error rates and is doing no retx. He found a short message tended to have close to a .5 BER while a long packet was less than .001 for the same power and data rate. Putting a tight filter inline of the antenna makes the idea of a software radio a little less attractive. \$\endgroup\$
    – Kellenjb
    Mar 28, 2011 at 15:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.