|
From: | George Nychis |
Subject: | Re: [Discuss-gnuradio] rssi questions |
Date: | Thu, 16 Aug 2007 15:48:03 -0400 |
User-agent: | Thunderbird 1.5.0.12 (X11/20070604) |
PS. We have a hacked up version of carrier sense working right now :)We're just using the C/S read register method to get a couple RSSI readings, computing an average, then writing the threshold to a register on the FPGA.
The packets are then marked with a carrier sense flag, which we stole a 'mbz' bit for now, however we think that the 'rssi' bits in the first word of the header should be reused as more bits for flags, so all of the flags in the header are back to back.
Leo already hacked up the FPGA code, checks the RSSI value and the threshold, and only transmits when the RSSI < threshold. We've verified this over the air already :D
- George George Nychis wrote:
Eric, we want feedback from you on this one :)I think you're right Jonathan, for performing carrier sense in the FPGA, we really do not need it in dB. Calculating the average to determine a threshold will get the job done with less the hassle. And right, if the host really wants it in dB, it can do the conversion.So here is what I want feedback on... how to communicate the RSSI to the host. What we figure is that the host should determine the threshold, in other words calculate the average and write it to a register that the FPGA can read. This saves the floating point computation on the FPGA, and the host can decide how many RSSI samples it wants to compute the threshold on.But, we've already determined that the 6-bits in the header are not enough for properly reading the RSSI from the FPGA. So, what do we want to do about this?We can store the RSSI in a register and read from it using C/S packets, then compute the average. This gives the full 32-bits.However, I still think it would be useful for each packet to contain an RSSI reading. I'm sure others would put use to this in the future. I propose adding a 32-bit RSSI field to the packet header. This doesn't even incur 1% overhead, it's ~.7% additional overhead per packet. Then with the higher bandwidth of USRP2, it's going to become even more insignificant.- George Johnathan Corgan wrote:George Nychis wrote:We want to compute the RSSI in dB on the FPGA, we're not even interested in the FPGA responding back with the RSSI at this point.Okay, but--why do you need units of dB? This is in the log domain, so at some point on the FPGA you'll need to take a logarithm of an amplitude. If it is for the user's benefit, then it is much simpler to do the conversion on the host.1. What exact information needs to be shared?The output of the ADC is a fixed multiple of the signal at the antenna input. Since the gain settings are controlled by the host, the host would need to calculate what the overall gain is and poke a register with a value the FPGA logic could use. Again, though, why do you need to get the actual RSSI? If you're going to use it for carrier-sense, then all you really need to do is threshold the average magnitude of the ADC output. You've already got that valuecalculated in rssi.v (perhaps that's a confusing name for the Verilog file.)The only downside of rssi.v output is that the time constant for averaging is fixed (to make the logic very simple, fast, and low-area.)2. Where can we get the information? I'm assuming when the daughterboards are initialized most of this information is available.It would be different for each daughterboard, but code could be added to the host daughterboard handling code to determine the overall antenna to ADC gain when the gain settings are set by the user. That overall gain value would then be poked into a register on the FPGA to be used by your code to get actual antenna power (assuming you still really need to do this.) Finally, for an AGC, the power measurement portion of the control loop doesn't need to be taken all the way to dB._______________________________________________ Discuss-gnuradio mailing list address@hidden http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Prev in Thread] | Current Thread | [Next in Thread] |