WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2015-Jun-16 00:37:23

Christian
Member
Registered: 2010-Feb-26
Posts: 124

OFDM RefDesign: Mid-Packet RSSI register

Hi,

we want to determine the received power level and use slightly averaged value RSSI values using the OFDM RefDesign v16.x/18.1. For this, we read the values from the mid-packet RSSI register (supermimo/OFDM Rx MIMO/Packet_Detection/RSSI-based PktDet/Mid-Packet RSSI Register) that averages over 16 packet header samples and stores the value right after the packet header. We found that the current gain has to be stored as well right after the packet header to obtain reasonable results.

The question that pops up now is: Is the gain control changing over the course of a packet reception or does it stay constant once it was selected in the very beginning.
If it is indeed changing over the course of a packet reception, then the implemented averaging of RSSI  values is entirely wrong if certain reception power ranges are reached, e.g. -40 to -45dBm due to a change in the gain curve.

Offline

 

#2 2015-Jun-16 08:58:06

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: OFDM RefDesign: Mid-Packet RSSI register

The AGC gain selections do not change during the reception. The AGC state machine is triggered by the Rx PHY packet detector. It selects the RF gain first (based on RSSI), then the baseband gain (based on abs(IQ)). Once the gains are selected the AGC holds these values until reset by the Rx PHY. This behavior is especially important in the OFDM and 802.11 ref designs, where the channel coefficients are estimated from the preamble and are used throughout the reception. If the Rx gains changed mid-reception the channel estimates would be invalid.

You should definitely record the RF gain when recording the RSSI. The baseband gain does not affect RSSI.

Offline

 

#3 2015-Jun-17 13:24:05

Christian
Member
Registered: 2010-Feb-26
Posts: 124

Re: OFDM RefDesign: Mid-Packet RSSI register

Now, I am observing that certain received dBm ranges are never "hit" if I sweep over the tx power settings while transmitting in the 5GHz band. The 2.4GHz band is way better.
I send a "rectangular" (red marked area) but I receive a heavily distorted rectangular in the figure below. However, note that no packets are corrupted.

(EDIT: graph: s. below)

This is definitely no error in my SNR calculation since I have also checked raw RSSI and RF values. There is a gap in case of the 5GHz band at roughly -42dBm.

After having checked the AGC core, I find some magic numbers (the slope factor of the curve in the top middle figure on pg 16 of the MAXIM data sheet) and, more importantly, I see no specific chain for the 5GHz band. This definitely needs to be adapted. Just changing the AGC thresholds in the warpphy.h is not eliminating this "hole", but rather moves it to higher or lower received dBm values.

My question is:
1. why you chose the "difficult" way of calculating SNRs according to the non-linear graphs instead of just comparing RSSI and RF selections?
2. Where do you guess I have to start modifications to close this gap?

Last edited by Christian (2015-Jun-20 07:35:17)

Offline

 

#4 2015-Jun-17 22:18:22

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: OFDM RefDesign: Mid-Packet RSSI register

What is the X axis in these plots? Is it the Rx power estimate calculated from (RSSI, RF_Gain)? Or is it (Tx_power - attenuation)?

The "cliff" around -40dBm looks to me like one of the AGC thresholds is set poorly for the frequency in use. The AGC core depends on the MAX2829's mapping of Rx power to RSSI, and on the Rx EVM vs Rx power vs RF gain selection. Both curves differ between 2.4 and 5 GHz. The AGC core is configured to switch from RF gain 3->2 and 2->1 as a function of averaged RSSI. The optimal switching points depend on the Rx EVM for each (Rx power, gain setting). The default thresholds are good for 2.4GHz. We never characterized the OFDM ref design at 5GHz. You can mimic the code in ofdm_AGC_Initialize() to adjust these thresholds as your switch frequencies. Each threshold value is interpreted by the AGC core as an approximate Rx power in dBm, stored as a Fix8_0 value.

1. why you chose the "difficult" way of calculating SNRs according to the non-linear graphs instead of just comparing RSSI and RF selections?

The original AGC core is more complicated than necessary; we just didn't know it at the time. We started from scratch when designing the AGC cores for the 802.11 and WARPLab reference designs. The newer AGC cores implement a direct RSSI -> RF gain selection mapping, skipping any translation to actual Rx power. The 802.11 ref design does implement an RSSI -> Rx power calculation in C code to facilitate various MAC functions (logging Rx powers, auto-rate decisions, etc). This mapping is based on an easy-to-calculate linear fit of actual Rx power, as calibrated by a spectrum analyzer. The mapping is pretty good across most Rx powers.

Offline

 

#5 2015-Jun-18 01:22:52

Christian
Member
Registered: 2010-Feb-26
Posts: 124

Re: OFDM RefDesign: Mid-Packet RSSI register

The X axis is the rx power estimate that is based on RSSI and RFgain. The measurements are done using a coax cable and a 30dB series attenuator. Regarding your suggestion to manipulate the default thresholds: I've already tried that, but the results are not satisfying. The gap of received (RSSI,RFgains) is moved along the x-axis but persists. Just as a side information: I've partitioned the 5GHz "RSSI vs P_in" curves into 6 segments each, but as I said before: This does not matter too much as even the reported raw RSSI and RF gain values have this gap.

I suspect the gap in case of 5GHz originates from the significant offset of the actual gain curve (p.19) and the linearization that is pretty accurate for 2.4GHz (the AGC core uses a pre-specified slope factor that only matches this linearization). I'll check the newer AGC core implementation and see how to fix this.

Two follow-up questions on that:
1. I saw the thresholds (the "old" from <v18 and the "new" from v18) but I cannot see why exactly those were selected for the 2.4GHz case. With respect to the EVM vs P_in curve on p.16, I would take -27dBm and -42dBm, which is in line with the switch point graph RX inband-output vs Gain on p.15. Why are the thresholds in the warpphy.h given as -24 (-30 in <v18) and -55 (-53 in <v18)?
2. I've never seen the low gain curve to be selected in the 5GHz band. The data sheet also states no medium-low gain switch point in the mid-bottom figure on p. 19 of the maxim data sheet. Can you confirm this?

Last edited by Christian (2015-Jun-18 02:16:48)

Offline

 

#6 2015-Jun-18 02:09:33

Christian
Member
Registered: 2010-Feb-26
Posts: 124

Re: OFDM RefDesign: Mid-Packet RSSI register

I checked a couple of cores:
WARPv3 OFDM RefDesign: ofdm_agc_mimo_plbw_v4_00_a : old design
WARPv2 WARPLab v7.5.1: w2_warplab_agc_plbw_v3_00_b : old design
WARPv3 WARPLab v7.5.1: w3_warplab_agc_axiw_v3_00_b : old design
WARPv3 80211 v1.2.0: wlan_agc_axiw_v1_00_n : old design

where "old design" means:
- hard-coded 2.4GHz linearization values that are used to translate RSSI to RX power
- comparison of RX power levels to power thresholds

I could not find an AGC core in the downloads and the repository that uses a direct RSSI >> RFgain selection.

Offline

 

#7 2015-Jun-19 09:28:50

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: OFDM RefDesign: Mid-Packet RSSI register

You're right; sorry. The new AGC cores still translate averaged RSSI to approximate Rx power with a simple linear mapping (rssi * slope + rf_gain_dependent_offset). I'm not sure what I was thinking of.

The gain-dependent offsets are controlled by software, as are the thresholds for selecting RF gain as a function of estimated Rx power. You can change these when changing center frequency if needed.

We ran a quick test with the 802.11 ref design to verify there are no inherent gaps in PER vs Rx power at 2.4 and 5 GHz.

We used two WARP v3 kits connected via a coax cable with a 30dB fixed attenuator and programmable attenuator in series. Tx power was set at 15 dBm, center frequency 5180 MHz. The independent variable was the programmable attenuator value, swept in 1dB steps. The plots below show the throughput (analogous to PER in this setup) and the estimated Rx power for each attenuation. This Rx power estimate is computed from the per-packet RSSI (captured at the end of the LTS) using the wlan_mac_low_calculate_rx_power() function in the 802.11 code. This function uses a lookup table we generated with a spectrum analyzer to measure actual Rx power vs RSSI, with different tables for 2.4 and 5 GHz.

http://warpproject.org/dl/misc/forums/80211_per_vs_pwr_5ghz.png

One explanation for the gap you're observing is as an artifact of using estimated Rx power as the X axis in the plots. If you use the actual independent variable (Tx gain, right?), do you see a consistent PER across Rx powers?

Also does your definition of PER count undetected packets as errors? In other words, are the total number of packets transmitted and total packets received the same in your experiment?

Offline

 

#8 2015-Jun-19 15:00:59

Christian
Member
Registered: 2010-Feb-26
Posts: 124

Re: OFDM RefDesign: Mid-Packet RSSI register

In the plot I've posted, I measured packets for each received power level:
- number of good headers & good packets
- number of good headers & bad packets
- number of bad headers
- entirely missed packets

The upper plot just shows the absolute number of recorded events for each received power level, while the lower shows the resulting packet error rate for each received power level. The plot is an average over 10 runs using a 30dB attenuator and modifying the TX power using the respective MAXIM TX offset register. No packet errors have been recorded and no missing packets. All 720k packets were received correctly, yet with this "strange" pattern.

I have played around with the AGC core, AGC values and packet detector values. My updated core looks like this:
http://i59.tinypic.com/33diefk.png

Although I can adjust the values on a much finer granularity, I am only able to move this dip around on the x-axis. This dip occurs exactly at the switching point between high RF gain and medium RF gain. If I move this switching point via the AGC thresholds, the dip moves in the graph. This pretty much rules out problems with the TX offset modification. We also tried different WARPv1 and v2 boards. All show consistent behavior. Could this be a problem with the (non-published) radio driver? we are still using 1.22a/1.30a.

I'll post tomorrow also an excerpt of RSSI/RF gains that also has this dip. Right now, I'm running out of ideas where this can come from. A last idea is the following: Maybe there is somewhere in the code a timing offset, i.e. RSSI averaging and storing to a register is maybe slightly slower than storing an RFgain to a register. This could potentially lead to wrong RSSI and RF gain combinations.

Last edited by Christian (2015-Jun-20 04:48:38)

Offline

 

#9 2015-Jun-19 16:38:15

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: OFDM RefDesign: Mid-Packet RSSI register

I guess I'm confused- isn't the dip just an artifact of the function rx_power_est(RSSI, G_RF) you're using to calculate the values on the X axis? What happens if you re-plot the same data using the actual independent variable (Tx gain) as the X axis? Similarly, what does your Tx gain (X) vs rx_power_est() (Y) plot look like? If this isn't a straight line, there's no chance the rx_power_est() vs PER will be flat. I would suggest investigating alternatives for rx_power_est(). The one we use for the 802.11 design tracks actual Rx power pretty well. It does require a LUT, though I suppose a comparable piecewise linear function could work too.

Offline

 

#10 2015-Jun-20 07:34:49

Christian
Member
Registered: 2010-Feb-26
Posts: 124

Re: OFDM RefDesign: Mid-Packet RSSI register

murphpo wrote:

isn't the dip just an artifact of the function rx_power_est(RSSI, G_RF) you're using to calculate the values on the X axis? What happens if you re-plot the same data using the actual independent variable (Tx gain) as the X axis?

No, I think it is not an artifact of the function rx_power_est! This is exactly the problem. Here follows a newly derived picture (update to very first figure in this thread using v16.2 on WARPv1) and an excerpt of the corresponding raw trace of RSSI/RFgain combinations. These combinations are obtained using the Mid-RSSI register to which I've added a AGC gain selection register as follows (there might be a problem as the RSSI averaging is slightly delayed to the RFgain values):
http://i61.tinypic.com/35ap4dl.png

For this measurement, I sent two packets for each TX gain setting, then lowered the TX gain setting by 1 and sent two packets again. This was done until the lowest TX power setting. Then, the TX power setting was reset to the maximum of 0x3F (63), and the entire process restarted. The resulting graph for a cable connection and the current AGC settings is ("typo" on x-axis: it is Received Power [dBm]!):
http://i62.tinypic.com/wlpwxy.png
Three strange things happen:
1. the dip at round about -41 to -45 dBm
2. a sharp spike at -25dBm and -26dBm, which could be explained by assuming the reported (RSSI,RFgain) are not correct, i.e. the wrong RFgain is reported (the offset between high and medium is roughly 19dB, so the reported -25dBm would actually be located at -44dBm, i.e. in the dip)
3. although I change the TX power over a range of 30dB and use a flat attenuator, the received spectrum covers a range of 34dB

An excerpt of raw RSSI/RFgains is this:

Code:

770,2
778,2
760,2
777,2
759,2
775,2
770,2
754,2
767,2
751,2
766,2
748,2
756,2
760,2
750,2
754,2
737,2
752,2
726,2
740,2
733,2
732,2
733,2
713,2
715,2
710,2
710,2
714,2
697,2
708,2
685,2
691,2
668,2
678,2
687,2
669,2
660,2
661,2
660,2
669,2
637,2
649,2
632,2
641,2
629,2
624,2
625,2
625,2
604,2
613,2
596,2
607,2
591,2
589,2
597,2
584,2
568,2
577,2
567,2
570,2
548,2
555,2
567,2
544,2
535,2
546,2
534,2
548,2
516,2
531,2
527,2
513,2
517,2
497,2
503,2
514,2
487,2
503,2
486,2
718,3
468,2
706,3
485,2
466,2
686,3
683,3
458,2
680,3
440,2
681,3
671,3
675,3
658,3
668,3
659,3
641,3
634,3
641,3
654,3
624,3
639,3
622,3
628,3
627,3
607,3
615,3
617,3
601,3
609,3
592,3
599,3
597,3
587,3
586,3
589,3
573,3
573,3
574,3
574,3
571,3
559,3
558,3
560,3
779,2
772,2
780,2
773,2
757,2
772,2
769,2
763,2
769,2
751,2
749,2
761,2
759,2
746,2
754,2
756,2
732,2
747,2
745,2
728,2
733,2
740,2
714,2
728,2
717,2
719,2
696,2
706,2
708,2
704,2
686,2
690,2
683,2
666,2
675,2
685,2
670,2
650,2
649,2
657,2
652,2
632,2
637,2
642,2
636,2
615,2
623,2
623,2
613,2
601,2
600,2
601,2
589,2
591,2
577,2
587,2
567,2
576,2
577,2
560,2
554,2
552,2
562,2
552,2
536,2
535,2
538,2
536,2
534,2
525,2
514,2
518,2
503,2
516,2
510,2
499,2
488,2
488,2
504,2
491,2
467,2
467,2
472,2
486,2
678,3
457,2
457,2
459,2
670,3
674,3
670,3
674,3
655,3
657,3
652,3
649,3
640,3
644,3
630,3
617,3
627,3
631,3
627,3
623,3
606,3
617,3
597,3
600,3
608,3
590,3
580,3
580,3
587,3
588,3
583,3
574,3
577,3
582,3
554,3
550,3
558,3
571,3

Each line in this trace represents a packet. As you can see (calculate), although I lower the TX power settings in 0.5dB to 1dB steps at the transmitter, a certain RSSI/rfgain range does not occur when the AGC switches from medium to high gain. It switches from roughly 465/2 to roughly 710/3, but indeed should switch to roughly 820/3. And exactly this gap leads to the dip in the plot above. As I've said in my last post above, playing around with the AGC thresholds just moves this gap to higher or lower RSSI/rfgain combinations but does not eliminate it.



murphpo wrote:

Similarly, what does your Tx gain (X) vs rx_power_est() (Y) plot look like? If this isn't a straight line, there's no chance the rx_power_est() vs PER will be flat.

For this, I think I have to mimic the "RSSI vs P_in" of the 5GHz band curves of the MAXIM data sheet. The C implementation relies on a segmentation of each curve into 6 piecewise linear segments. Analyzing the segmentation and parametrization of each segment analytically gives this (note that X and Y axis are switched in comparison to the MAXIM data sheet):
http://i58.tinypic.com/2qvutn7.png
The AGC core switching point between high and low should be roughly at -40dBm, while there is no "automatic" selection of the low gain curve since the MAX2829 is not using this by itself when using the 5GHz band.



murphpo wrote:

I would suggest investigating alternatives for rx_power_est(). The one we use for the 802.11 design tracks actual Rx power pretty well. It does require a LUT

I will look into this now, but I assume this will not help as the reported RX RSSI/RFgain combinations already have the dip.

Last edited by Christian (2015-Jun-20 12:23:15)

Offline

 

#11 2015-Jun-22 11:27:55

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: OFDM RefDesign: Mid-Packet RSSI register

Hey Christian,

I don't see how an AGC problem can explain what you are seeing. Ultimately, if you are receiving every packet you are sending over your 30 dB range of transmit power, then the AGC is choosing "good enough" gains. Maybe tweaks to thresholds could improved EVM modestly, but everything is all there. Furthermore, there is a causality problem in blaming the AGC for "incorrect" Rx powers -- the Rx power is dictated by the Tx power and attenuation through your RF cabling. Even if the AGC chooses bad gains, the design should be able to give an accurate estimate of Rx power. The explanation that makes the most sense to me is an incorrect mapping of (RSSI, RF Gain) -> Power in dBm (i.e. a flaw in rx_power_est).

Christian wrote:

Three strange things happen:
1. the dip at round about -41 to -45 dBm
2. a sharp spike at -25dBm and -26dBm, which could be explained by assuming the reported (RSSI,RFgain) are not correct, i.e. the wrong RFgain is reported (the offset between high and medium is roughly 19dB, so the reported -25dBm would actually be located at -44dBm, i.e. in the dip)
3. although I change the TX power over a range of 30dB and use a flat attenuator, the received spectrum covers a range of 34dB

All three of these observations are consistent with a flaw in rx_power_est.

Christian wrote:

It switches from roughly 465/2 to roughly 710/3, but indeed should switch to roughly 820/3. And exactly this gap leads to the dip in the plot above. As I've said in my last post above, playing around with the AGC thresholds just moves this gap to higher or lower RSSI/rfgain combinations but does not eliminate it.

Where does your expectation of 820/3 come from? Is it purely those low-resolution graphs in the MAX2829 datasheet? Your experiment shows empirically that 710/3 is to be expected over 820/3. No amount of threshold changing in the AGC is going to change the relationship between RSSI and RF gain. You now have evidence that this relationship isn't what you thought so rx_power_est should be updated accordingly. It's worth noting that our Rx power calculation in the 802.11 design is strictly empirical and not derived from the data sheet for similar reasons. We have an explicit Rx power lookup table that is keyed off of RSSI and RF gain selection.

Patrick had suggestions in his earlier responses that remain useful for further investigation.

murphpo wrote:

isn't the dip just an artifact of the function rx_power_est(RSSI, G_RF) you're using to calculate the values on the X axis? What happens if you re-plot the same data using the actual independent variable (Tx gain) as the X axis?

Is the result of that experiment flat? Is the range 30 dB instead of 34 dB?

murphpo wrote:

Similarly, what does your Tx gain (X) vs rx_power_est() (Y) plot look like? If this isn't a straight line, there's no chance the rx_power_est() vs PER will be flat.

The plot you showed was rx_power_est() (Y) vs. RSSI (X). Having the actual independent variable in the graph is important. Tx gain (X) vs rx_power_est() (Y) needs to be linear, otherwise all bets are off.

Offline

 

#12 2015-Jun-23 04:06:49

Christian
Member
Registered: 2010-Feb-26
Posts: 124

Re: OFDM RefDesign: Mid-Packet RSSI register

chunter wrote:

Where does your expectation of 820/3 come from? Is it purely those low-resolution graphs in the MAX2829 datasheet? Your experiment shows empirically that 710/3 is to be expected over 820/3. No amount of threshold changing in the AGC is going to change the relationship between RSSI and RF gain. You now have evidence that this relationship isn't what you thought so rx_power_est should be updated accordingly. It's worth noting that our Rx power calculation in the 802.11 design is strictly empirical and not derived from the data sheet for similar reasons. We have an explicit Rx power lookup table that is keyed off of RSSI and RF gain selection.

The expectation comes indeed from the graphs as we do not have an external device handy with which to measure the expected input received power. Yet I assumed these graphs were at least roughly accurate, but obviously they differ quite significantly. As it seems, regarding your comment, you also made a similar observation.

murphpo wrote:

Similarly, what does your Tx gain (X) vs rx_power_est() (Y) plot look like? If this isn't a straight line, there's no chance the rx_power_est() vs PER will be flat.

If I cannot rely on the graphs in the data sheet, then the rx_power_est is obviously wrong. Find below a histogram plot with three distinctive TX power settings (max, medium and min) and the corresponding TX power vs. received power plot.
http://i62.tinypic.com/xf52yu.png
http://i57.tinypic.com/fjj5a9.png
As you can see, the gap produces a significantly different slope (plus the slight deviation for very high TX powers). The underlying calculation is based on the data sheet and the graph therein. Obviously, the graph is wrong.


Here are the results of the LUT approach. I have taken over the LUT from WLAN 802.11 design plus the calling functions. To match it to the 30dB attenuation, I extended the LUT range following the "pattern" in the 80211 design. The RSSI input may be different though as I am still using the MidPacket RSSI register of the OFDM RefDesign. The dip is not as pronounced as before but still recognizable (top left is 2.4GHz, bottom right is 5.7GHz)
http://i61.tinypic.com/2r2u2yo.png

Last edited by Christian (2015-Jun-23 05:23:23)

Offline

 

#13 2015-Aug-18 08:36:13

Christian
Member
Registered: 2010-Feb-26
Posts: 124

Re: OFDM RefDesign: Mid-Packet RSSI register

Hi,

I am still trying to figure it out. Meanwhile, I suspect the MAX2829 chip to not send a correct pattern by modifying the software TXpower setting. I want to test our WARPv3 boards using the OFDM RefDesign first. However, the new radio controller (driver) does not expose the RSSI directly. Can anyone tell me, if the packet-independent RSSI values is stored in some register, and if so, in which?

Christian

Offline

 

#14 2015-Aug-18 09:45:14

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: OFDM RefDesign: Mid-Packet RSSI register

Patrick can correct me if I'm wrong, but I don't believe there is a register that is always latching outputs of the 10 MHz RSSI signal. You'd have to add a register somewhere in the design and feed it values from the RSSI port if you want that.

Offline

 

#15 2015-Aug-18 10:21:52

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: OFDM RefDesign: Mid-Packet RSSI register

The new radio_controller (used on all WARP v3 designs and recent WARP v3 designs) does not latch the RSSI ADC output; the Rx PHY design must capture RSSI as needed. The WARPLab ref design is your best option if you need to capture a continuous stream of RSSI values.

Offline

 

#16 2015-Aug-21 10:01:06

Christian
Member
Registered: 2010-Feb-26
Posts: 124

Re: OFDM RefDesign: Mid-Packet RSSI register

I tried to latch it with an own core but I only receive garbled results for both antennas when I enable HW control in the radio_controller. If I enable SW control, I can read it correctly, but not transmit/receive automatically. If I leave HW control enabled, the RSSI values of the currently activated antenna are wrong (random values close to zero).

The old reference design offered a function (WarpRadio_v1_readRSSIData()) that directly read values from a register and reported the latched RSSI value, even in case of no transmission. Did the previous radio_controller do something else in hardware to read in and latch the correct RSSI value?

Last edited by Christian (2015-Aug-21 10:03:13)

Offline

 

#17 2015-Aug-21 15:20:34

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: OFDM RefDesign: Mid-Packet RSSI register

The WarpRadio_v1_RSSIData() function read a register in the radio_controller core. That register was clocked by the PLB bus clock. The RSSI data signals were clocked by the RSSI ADC clock, possibly asynchronous to the processor bus. This is one reason we removed the register from the core.

To mimic the old radio_controller RSSI register, you should add a D flip-flop to your custom HDL/Sysgen that captures the RSSI data bus. The DFF should be clocked by a clock signal that is synchronous to the RSSI ADC clock. The reference designs run everything (processor, busses, cores, I/Q converters, RSSI ADC) synchronous to the common sampling reference clock, so using one of the existing 10/20/40 MHz clocks would be fine.

Keep in mind the MAX2829 analog RSSI signal is only meaningful when the MAX2829 is in Rx mode, so your code/logic should only use digital RSSI values when you're sure the radio is actually receiving. Reading the RSSI data out-of-sync from the transceiver mode could give all sorts of garbage values.

Offline

 

Board footer