rssi: calculate signal and noise in firmware

[el-han]

Since the RSSI and SNR calculations sometimes deliver unreliable values, I would like to propose a new RSSI and SNR algorithm.

Until now, the firmware calculated the RSSI value as an exponential moving average. Since it has a low pass behaviour, it generates values with a strong bias to its initial value of 0 (-54 dBm). It was replaced by a fixed average over up to 40 RSSI values (typically 35 - 38 RSSI values are acquired while waiting for the DMA to fill).

Before an USB packet is transmitted, the signal and noise values are calculated:

1. calculate the average between the minimal and the maximal RSSI value
2. each of the 40 RSSI values below that value are considered noise values, each of the 40 RSSI values above that value are considered signal values
3. calculate the average of all signal values
4. calculate the average of all noise values
5. add min, max, avg, count, signal and noise values to the package header

For now I use the two reserved bytes in the USB packet header for transmitting the signal and noise values to the host.

RSSI values are stored as raw dBm values without the 54 dB offset of the CC2400 radio chip.

I have also made cb_btle() print the signal rssi value of a packet instead of its minimal rssi value, which I think was one topic of #128 .

I am a little worried about using the reserved bytes in the USB packet header. So please feel free to discuss my changes.

[orgua]

This PR made me aware of an issue. YES, technically you can sum up the received power in decibel-scale. BUT it doesn't mean you are allowed to do so if you want to calculate the mean. I see this is no new bug. You won't get around the conversion to linear scale and back. lookup-tables and linear interpolation are your friend.