Measure BER

GNU Radio
1

Hi all,
I’m currently working on a GSMK modem, and I would like to calculate the
BER
of the link. I send data using gr.vector_source_b( ) connected to a GMSK
modulator/demodulator and receive the signal in gr.vector_sink_b( ).

  1. How can I measure BER from the vector_source and vector_sink ?
  2. Does a BER calculator recovering from clock shifting (bit lost by
    clock
    sliding) exist ?
    Thanks !
    –
    View this message in context:
    http://www.nabble.com/Measure-BER-tp14952951p14952951.html
    Sent from the GnuRadio mailing list archive at Nabble.com.
2

Hi,

BER is defined as the % of bits that have errors to the total number of
bits. Therefore, you need to calculate the number of incorrect bits.
To do this you would need to know the correct bits to compare your
received bits to. You can then easily compute the number of incorrect
bits.

Therefore, if the input to gr.vector_source_b() is your input data, you
would compare it to the output of gr.vector_sink_b() and calculate the
bit difference. If 1 bit out of 10^3 bits are different, your BER is
1/10^3. The more input, the more accurate your BER estimate is.

I don’t think a BER calculator exists in GR, but it shouldn’t be that
difficult. The block would take two input streams, one being the
correct data and the other being the decoded data. It could then
compare the two.

Or you could compare the two outside of GNU Radio pretty easily.

It’s not clear to me if you’re performing the modulation and
demodulation on the same machine. If so you have easy access to both
data sets. Otherwise, transfer the known data to the receiver in a 100%
accurate method and then compare.

  • George
3

George N. wrote:

the bit difference. If 1 bit out of 10^3 bits are different, your BER
is 1/10^3. The more input, the more accurate your BER estimate is.

I don’t think a BER calculator exists in GR, but it shouldn’t be that
difficult. The block would take two input streams, one being the
correct data and the other being the decoded data. It could then
compare the two.
The only difficulty is the delay introduced by the flowgraph,
specifically through filters. You can brute force this by looking at the
output and figuring out the delay. I noticed, though, when I was working
on my dissertation, certain flow graphs would have an uncertain delay,
though I wasn’t sure why (I think it was GMSK, too, which would have a 7
or 8 sample delay on any given run).
Or you could compare the two outside of GNU Radio pretty easily.

It’s not clear to me if you’re performing the modulation and
demodulation on the same machine. If so you have easy access to both
data sets. Otherwise, transfer the known data to the receiver in a
100% accurate method and then compare.
Much easier on the same machine. The BER block I wrote works well in
this case and automatically adjusts for the delay by looking for a start
packet. It’s a bit crude and awkward to use the block, which is why I
haven’t checked it into the project yet. The results, though, were
very good. Within a few tenths of a dB to theory. GMSK had a problem
at SNRs lower than about 5 dB.

Tom

4

Hi!

I’ve started performing modulation and demodulation on the same machine
but
the main purpose is to make them work separately afterwards.
I’ve seen some BER values on the forums and I was wondering if an
“official”
block had already been developed to measure it.

  1. Tom, May I please have a look at your block calculating BER?

  2. When comparing data sent and data received, how can we detect bit
    lost in
    order to avoid clock shifting? In other words, if I’m sending “11010110”
    for
    example, and that the 4th bit is lost, a simple comparison will compare
    tx :
    “11010110” with rx : “1100110”. Detecting a lost is easy because the
    number
    of bits in reception will be inferior to the number of bits sent, but
    how
    can continue to compare the rest correctly?
    –
    View this message in context:
    http://www.nabble.com/Measure-BER-tp14952951p14998913.html
    Sent from the GnuRadio mailing list archive at Nabble.com.

5

irene159 schrieb am 2008-01-21 16:01:

Hi!

  1. When comparing data sent and data received, how can we detect bit lost in
    order to avoid clock shifting? In other words, if I’m sending “11010110” for
    example, and that the 4th bit is lost, a simple comparison will compare tx :
    “11010110” with rx : “1100110”. Detecting a lost is easy because the number
    of bits in reception will be inferior to the number of bits sent, but how
    can continue to compare the rest correctly?

You would use a known sequence which you synchronize on. This can be a
pseudo-noise sequence or a long pattern. It should have low
autocorrelation except for a shift of 0. In hardware you would run the
sequence a slightly lower or higher rate and try to lock. If the
receiver-generated and the received sequence are approximately equal,
you get lock and run the sequence at the right speed.

In software? Dunno, is correlating fast and robust?

Patrick

Engineers motto: cheap, good, fast: choose any two
Patrick S.
Student of Telematik, Techn. University Graz, Austria