RSSI value in inband code

GNU Radio
1

Hi

after looking at the verilog code for some time, these are my results:

in module usrp_inband_usb, for each of the four aux adcs, the signal
level is
read from the adc and an gliding average of the rssi and an saturation
indicator is is calculated. The rssi value is put but into the lower 16
bits
of an 32 bit bus, which is passed on through the module rx_buffer_inband
and
reaches the module packet_builder.

In packet_builder, the rssi bus of the adc corresponding with the
channel
which is transmitted is selected. Until here, everything is fine.

As said before, the rssi value is in the 16 lower bits of the rssi bus.
When
looking at the calculation of the rssi value, it is apparent that it is
a IIR
filter with output value in the range [0…0x7ff] (max value is
determined by
the max absolute value of the aux adc, which is 0x7ff).

Now, the packet_builder takes the lower 6 bits of the 16 bit register
with an
value range corresponding to 11 bits and puts it into the usb packet. So
as
soon as the average value of the adc is higher than 0x3f (63), the rssi
value
in the usb packet will be just noise.

Proposal:
Change the rssi value to a logarithmic encoding. With a 3.3 split, 10
bits can
be encoded, which is almost the range of the aux adc (11bit). Step size
is
about 0.1dB.

A verilog module for encoding the rssi value is attached. I have no
tools for
verilog, so I did not test it. Dont know if it works, and if the the
changes
in the packet_builder for getting the log value from the linear value is
correct.

Would be nice if anyone could test this and pass an fpga firmware on to
me.

Thanks,

Stefan

2

Hi Stefan,

There has been constant back and forth between a lot of us on the list
about what exactly should be in the RSSI field. I’m not the one who
wrote the RSSI calculation, but myself and another student are
responsible for the in-band implementation and what bits get put into
the header.

It’s obviously too small to contain the full RSSI reading, the lowest
bits are not very useful, and the top most bits may not contain the
information we want either. We had tossed around the idea of just
reporting the location of the MSB. I had modified it at one time to
take intermediate bits for my own purpose… there’s just never been a
great solution.

Your proposed method is interesting. I think it would provide much more
useful information than any method we’ve proposed so far. The code
you’ve provided definitely has some syntax errors, but all-in-all is in
the right direction. We do have an environment setup for rebuilding the
FPGA code here, and I’d love to do it for you but my time is kind of
tight right now as I have my PhD qualifying exam next week. What I
could do is give you remote access to the environment for you to fix up
your syntax and actually build a new firmware image. Then you could
test it and everything. If you’re interested in this, e-mail me off
list and we can work it out.

  • George

Stefan Brüns wrote: