Author Topic: Real time RSSI measurement broken RFM69CW?  (Read 25966 times)

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #45 on: January 24, 2016, 01:31:04 PM »
My conclusions are:

1) If you are receiving genuine packets you should wait for the PayloadReady interrupt and read the RSSI immediately before emptying the FIFO because PayloadReady freezes the RSSI register. Once you empty the FIFO, or take out of RX mode, the RSSI register will start to change again.

2) My experiments with unlimited packet length seem to imply a strangeness with the RSSI levels reported. If a packet starts to be received it appears the correct value is sometimes not put into the RSSI register. When using variable length mode a PayloadReady is generated, and the correct value is put in the RSSI register at that point. This may have implications for using unlimited packet length mode and reading the RSSI assiciated with it.

3) Waiting for an RSSI interrupt, reading the RSSI register and restarting the receiver appears to be the most reliable.

Here's the code I'm using to sample at 1ms resolution. I'm not convinced it really is 1ms, if you restart by switching to STANDBY and then to RX mode (which waits for MODEREADY) the cycle time will drop to 2.5ms with no delays. I'm beginning to suspect this is the fastest possible, there certainly appears to be a limit on the maximum rate at which the RSSI register updates and it is in the same order of 2.5ms.

Code: [Select]
void rssiLoop(void)
{
    int8_t rssi[20];
    uint8_t flags1[20];
    uint8_t flags2[20];
    uint16_t loopCount = 0;
    uint8_t x;
    uint16_t cnt1= 0;
    uint16_t cnt2= 0;

    rfm69WrSpi(REG_RSSITHRESH, 0xFF);  // permanently trigger
    setRfm69Mode(RX_MODE); // set to RX mode

    while(1)
    {
        loopCount++;
   
        for(x=0; x<20; x++)           
        {

            nLEDON_PORT |= (1 << nLEDON_BIT); // used with 'scope to measure cycle time
            // wait for RSSI interrupt
            while((rfm69RdSpi(REG_IRQFLAGS1) & IRQFLAGS1_RSSI)==0);
            nLEDON_PORT &= ~(1 << nLEDON_BIT); // used with 'scope to measure cycle time

            // sample RSSI and flags
            rssi[x] = -(rfm69RdSpi(REG_RSSIVALUE)/2);
            flags1[x] = rfm69RdSpi(REG_IRQFLAGS1);
            flags2[x] = rfm69RdSpi(REG_IRQFLAGS2);
 
            // restart receiver
            rfm69WrSpi(REG_PACKETCONFIG2, (PACKETCONFIG2_RESTARTRX));

            // slows sampling down to ~1ms
            _delay_us(800);
        }

        // dump out if we see some activity
        if((rssi[5] > -60) && (rssi[10] > -60))
        {
            SYS_DEBUG((PSTR("cnt1 = %d, cnt2 = %d\r\n"),cnt1,cnt2));
            for(x=0; x<20; x++)
            {
                SYS_DEBUG((PSTR("%d.%d: irqFlags1=0x%X, irqFlags2=0x%X, RSSI=%d\r\n"),loopCount,x,flags1[x],flags2[x],rssi[x]));
            }
        }
    }   
}

Here's an example of the output, this is sampling a packet which takes just over 10ms to transmit:

Code: [Select]
2949.0: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-107
2949.1: irqFlags1=0x98, irqFlags2=0x0, RSSI=-35
2949.2: irqFlags1=0x98, irqFlags2=0x0, RSSI=-34
2949.3: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-34
2949.4: irqFlags1=0x98, irqFlags2=0x0, RSSI=-35
2949.5: irqFlags1=0x98, irqFlags2=0x0, RSSI=-33
2949.6: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-33
2949.7: irqFlags1=0x98, irqFlags2=0x0, RSSI=-34
2949.8: irqFlags1=0x98, irqFlags2=0x0, RSSI=-34
2949.9: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-34
2949.10: irqFlags1=0x98, irqFlags2=0x0, RSSI=-35
2949.11: irqFlags1=0x98, irqFlags2=0x0, RSSI=-32
2949.12: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-32
2949.13: irqFlags1=0x98, irqFlags2=0x0, RSSI=-107
2949.14: irqFlags1=0x98, irqFlags2=0x0, RSSI=-107
2949.15: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-107
2949.16: irqFlags1=0x98, irqFlags2=0x0, RSSI=-104
2949.17: irqFlags1=0x98, irqFlags2=0x0, RSSI=-104
2949.18: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-104
2949.19: irqFlags1=0x98, irqFlags2=0x0, RSSI=-107

Edit: Curiously the cycle time changes to 3ms if instead of waiting for RSSI in the loop we wait for RXREADY. This fits with your observation that waiting for RXREADY is more reliable. I think 3ms is probably the fastest you can sample different values, any faster and there's repetition.

Mark.
« Last Edit: January 24, 2016, 01:43:40 PM by perky »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #46 on: January 24, 2016, 07:33:49 PM »

Here's the code I'm using to sample at 1ms resolution. I'm not convinced it really is 1ms, if you restart by switching to STANDBY and then to RX mode (which waits for MODEREADY) the cycle time will drop to 2.5ms with no delays. I'm beginning to suspect this is the fastest possible, there certainly appears to be a limit on the maximum rate at which the RSSI register updates and it is in the same order of 2.5ms.

The code in your most recent post doesn't seem to indicate what bitrate you're using, but according to the datasheet the RSSI sample time is partially a function of bitrate:

Code: [Select]
RSSI sample time: Trssi = 2 x int(4.RxBw.Tbit)/(4.RxBw) (aka TS_RSSI)
Unless I'm mistaken, Tbit is the time it takes to transmit/receive one bit, and that, of course, would depend on the bitrate.  It was partially for that reason that in earlier posts I had set the bitrate of the receiver Moteino at 300kbps, so as to get the fastest sample rate.  I didn't post it, but IIRC I had timed it (using calls to "micros()") as taking something like 180 microseconds to go from entering Rx-mode to actually getting RSSIvalue.

I'm not sure if that squares with the datasheet math, though, because I'm confused with its notation.  Does "4.RxBw.Tbit" mean "4 times RxBw times Tbit"?

I hadn't thought to check, but now I wonder whether slower sample rates would have any effect on measured RSSI?  i.e. is there a narrower spread of measured RSSI, or is it about the same but takes longer to acquire?  I presumed it has no effect.

« Last Edit: January 24, 2016, 07:35:28 PM by WhiteHare »

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #47 on: January 25, 2016, 05:29:54 AM »
The RSSI sample rate (TRSSI) is supposedly proportional to the bit rate period (Tbit), so the faster you send data the faster the sampling is. I actually use 12kb/s, so 10ms to send a full packet of 14 bytes including preamble and this gives around 166us TRSSI. However it's hard to see how bit rate comes into it at the beginning of a packet when looking at the preamble when bit rate and even exact frequency is not yet known. Still that's what the datasheet says...

I was measuring 2.5ms cycle time from getting an RSSI interrupt to RSSI interrupt, when resetting by putting into standby and back to RX in the loop. I note that your code didn't poll for MODEREADY when changing modes, and this is actually the major part of that delay. The values I was reading for RSSI had repetitions if I tried to poll any faster and only seemed to change every 2.5ms or so.

emjay

  • Full Member
  • ***
  • Posts: 119
  • Country: nl
Re: Real time RSSI measurement broken RFM69CW?
« Reply #48 on: January 25, 2016, 11:32:04 AM »
@perky,
Quote
However it's hard to see how bit rate comes into it at the beginning of a packet when looking at the preamble when bit rate .... is not yet known.

Au contraire, for this family of chips the transmit bit rate is one of the few things you must know (or at least a reasonable estimate) to successfully frame the incoming stream.  The preamble is used for figuring where the bit cell transition edges should fall, not some 'autobaud' detection (+ lots of other work to do in that brief period for AGC, AFC if enabled).

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #49 on: January 25, 2016, 12:05:15 PM »
Good point about polling for ModeReady.  I'll fix that in the setup function, so that it's polled before setting RSSIThreshold.  The main loop now runs using RxRestart, so I'm assuming (but haven't actually checked) that ModeReady is always HIGH there.

I notice that Semtech has a reference design for an SX1231, and it doesn't appear to utilize a metal can of any kind to shield against unwanted RF sneaking into the RF front end:  http://www.semtech.com/images/datasheet/sm1231_user-guide.pdf
I presume this is what Semtech used to measure its benchmarks?

Aside from that, I haven't found any other vendors other than HopeRF offering a SX1231 or SX1231h module, so there seems to be nothing else to compare against.


perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #50 on: January 25, 2016, 12:29:08 PM »
@emjay: I agree, but we're talking about reading abitrary RSSI values without necessarily receiving anything. That could be from any RF source, at any bit-rate or OOK modulated, or even a constant carrier. So the bit rate dependence on RSSI measurement at the very beginning doesn't mean much, you're just measuring energy in a small bandwidth over a certain sampling period of time. I can see it being more dependent later on as you're receiving a packet and maybe updating your RSSI dynamically. It seems then that your programmed bit rate will set that sample time period.

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #51 on: January 25, 2016, 12:35:06 PM »
@WhiteHare: Microchip do a sx1231 clone chip, and Freescale also appear do the same silicon but with an embedded 32bit micro on chip. The latter has much better technical support and their datasheets are more easily read, so it might be an idea to post on a Freescale forum.
Mark.

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #52 on: January 25, 2016, 01:34:52 PM »
BTW, I was finding issuing a restart introduced a delay, but not immediately. The 'scope was showing a delay in the LED toggling inserted into a stream of fast reads. So I wondered what would happen instead of restarting I waited for a PayloadReady and cleared the FIFO, this apparently is also a reset condition. So I tried the code below, and this appears to update the RSSI register with a 100us cycle time (at least when I look at noise the values update on practically every sample) and there are no extra delays introduced by restarting:
Code: [Select]
void rssiLoop(void)
{
    int8_t rssi[20];
    uint8_t flags1[20];
    uint8_t flags2[20];
    uint16_t loopCount = 0;
    uint8_t x;
    uint16_t cnt1= 0;
    uint16_t cnt2= 0;

    rfm69WrSpi(REG_RSSITHRESH, 0xFF);  // permanently trigger
    setRfm69Mode(RX_MODE); // set to RX mode

    while(1)
    {
        loopCount++;
   
        for(x=0; x<20; x++)           
        {

            nLEDON_PORT |= (1 << nLEDON_BIT); // used with 'scope to measure cycle time
            // wait for RSSI interrupt
            while((rfm69RdSpi(REG_IRQFLAGS1) & IRQFLAGS1_RSSI)==0);
            nLEDON_PORT &= ~(1 << nLEDON_BIT); // used with 'scope to measure cycle time

            // sample RSSI and flags
            rssi[x] = -(rfm69RdSpi(REG_RSSIVALUE)/2);
            flags1[x] = rfm69RdSpi(REG_IRQFLAGS1);
            flags2[x] = rfm69RdSpi(REG_IRQFLAGS2);
 
            if(flags2[x] & IRQFLAGS2_PAYLOADREADY)
            {
                while(rfm69RdSpi(REG_IRQFLAGS2) & IRQFLAGS2_FIFONOTEMPTY)
                {
                    rfm69RdSpi(REG_FIFO);
                }
            }

        }

        // dump out if we see some activity
        if((rssi[6] > -120) && (rssi[9] > 120))
        {
            SYS_DEBUG((PSTR("cnt1 = %d, cnt2 = %d\r\n"),cnt1,cnt2));
            for(x=0; x<20; x++)
            {
                SYS_DEBUG((PSTR("%d.%d: irqFlags1=0x%X, irqFlags2=0x%X, RSSI=%d\r\n"),loopCount,x,flags1[x],flags2[x],rssi[x]));
            }
        }
    }   
}

Here's an example of that, the register is updating quickly on 100us cycle:
Code: [Select]
33.0: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-111
33.1: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-111
33.2: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-107
33.3: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-110
33.4: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-110
33.5: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-112
33.6: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-112
33.7: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-112
33.8: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-107
33.9: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-107
33.10: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-106
33.11: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-106
33.12: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-108
33.13: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-109
33.14: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-109
33.15: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-110
33.16: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-111
33.17: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-105
33.18: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-107
33.19: irqFlags1=0xD8, irqFlags2=0x0, RSSI=-107

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #53 on: January 26, 2016, 07:40:56 AM »
Once you empty the FIFO, or take out of RX mode, the RSSI register will start to change again.

You probably know this already, but if not or for the benefit of others who may be reading this thread, there's this as the related background datasheet info:  " If AutoRxRestartOn = 1, after the controller has emptied the FIFO the receiver will re-enter the WAIT mode described above, after a delay of InterPacketRxDelay, allowing for the distant transmitter to ramp down, hence avoiding a false RSSI detection. "

BTW, I did try looking, but I didn't find any Microchip chips or modules that  looked very close to the SX1231h.
« Last Edit: January 26, 2016, 11:06:36 AM by WhiteHare »

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #54 on: January 26, 2016, 10:29:51 AM »
Well there's the MRF39RA:
ww1.microchip.com/downloads/en/DeviceDoc/40001778A.pdf
This has silicon rev 2.3, so probably sx1231 based rather than sx1231h which is rev 2.4.

Actually in my code I do set AutoRxRestartOn in my initialization code, which explains why it works :)
« Last Edit: January 26, 2016, 10:33:03 AM by perky »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #55 on: January 26, 2016, 11:37:14 AM »
Well there's the MRF39RA:
ww1.microchip.com/downloads/en/DeviceDoc/40001778A.pdf
This has silicon rev 2.3, so probably sx1231 based rather than sx1231h which is rev 2.4.

That's interesting.  Thanks for the link.   It's not a transceiver, though.  It's receiver-only.  Maybe it is the SX1239?  http://www.semtech.com/images/datasheet/sx1239.pdf

Just a wild thought, but given the present context, I wonder whether being separated as it is from the transmitter section means it would experience less RF noise?

[Edit: If it ever comes to that, then for testing purposes I notice Microchip does at least offer Rx eval boards at a much lower price than the Semtech RxTx eval boards:  http://www.digikey.com/product-search/en?pv183=132&FV=fff40036%2Cfff802bc&k=qwikradio&mnonly=0&newproducts=0&ColumnSort=0&page=1&quantity=0&ptm=0&fid=0&pageSize=25]
« Last Edit: January 26, 2016, 01:00:09 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #56 on: January 27, 2016, 12:39:44 AM »
I'm generating better data now, and it's causing me to change my conclusions.  Not all the new data is in yet, but my conclusions are trending  towards Perky's conclusions.

The first big surprise was that waitng for RxReady yielded results that were strikingly similar to waiting for RSSI to go HIGH.  Next, I completely separated RSSI capture from printing of captured results, so that the printing doesn't interfere with capturing.  When I did that, I got results like this:
Code: [Select]
1.0. RSSI=-82
1.1. RSSI=-82
1.2. RSSI=-79
1.3. RSSI=-85
1.4. RSSI=-93
1.5. RSSI=-98
1.6. RSSI=-105
1.7. RSSI=-104
1.8. RSSI=-104
1.9. RSSI=-107
2.0. RSSI=-82
2.1. RSSI=-82
2.2. RSSI=-78
2.3. RSSI=-87
2.4. RSSI=-95
2.5. RSSI=-103
2.6. RSSI=-104
2.7. RSSI=-106
2.8. RSSI=-107
2.9. RSSI=-109
3.0. RSSI=-82
3.1. RSSI=-82
3.2. RSSI=-79
3.3. RSSI=-87
3.4. RSSI=-93
3.5. RSSI=-104
3.6. RSSI=-105
3.7. RSSI=-101
3.8. RSSI=-104
3.9. RSSI=-101
4.0. RSSI=-82
4.1. RSSI=-82
4.2. RSSI=-80
4.3. RSSI=-86
4.4. RSSI=-92
4.5. RSSI=-101
4.6. RSSI=-106
4.7. RSSI=-106
4.8. RSSI=-104
4.9. RSSI=-101
5.0. RSSI=-82
5.1. RSSI=-82
5.2. RSSI=-82
5.3. RSSI=-88
5.4. RSSI=-93
5.5. RSSI=-109
5.6. RSSI=-110
5.7. RSSI=-100
5.8. RSSI=-104
5.9. RSSI=-103
Some things to notice:
1.  The first two measurements in each cycle tend to be equal.
2.  The first measurement in each cycle tends to agree (similar magnitude)  the first measurement in the other cycles.
3.  The first measurement in each cycle tends to have the highest value (i.e. least negative) in the cycle.  From there, subsequent measurements in the same cycle trend to a lower lower RSSI (more negative).  It's almost as though there were a certain amount of voltage stored on the RSSI Analog-to-Digital converter at the start of a cycle, and then each subsequent measurement bled off more and more of the voltage without replenishing it.
« Last Edit: January 27, 2016, 12:46:35 AM by WhiteHare »

emjay

  • Full Member
  • ***
  • Posts: 119
  • Country: nl
Re: Real time RSSI measurement broken RFM69CW?
« Reply #57 on: January 27, 2016, 04:42:59 AM »
@WhiteHare,

Just to check - AGC and AFC are disabled for these tests?

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #58 on: January 27, 2016, 10:22:54 AM »
@WhiteHare,

Just to check - AGC and AFC are disabled for these tests?

Good question, and I think I need help/guidance in order to answer it.  I'm not sure how to check whether or not they are disabled, because I don't see an explicit enabled/disabled bit for either one.  So, I did just now capture what seemed to be the most relevant registers just prior to taking each RSSI reading, and the results were:

Code: [Select]
1.0. RSSI=-80, regAFCFEI=B10000, regLNA=B10000
1.1. RSSI=-99, regAFCFEI=B10000, regLNA=B10000
1.2. RSSI=-103, regAFCFEI=B10000, regLNA=B10000
1.3. RSSI=-107, regAFCFEI=B10000, regLNA=B10000
1.4. RSSI=-108, regAFCFEI=B10000, regLNA=B10000
1.5. RSSI=-103, regAFCFEI=B10000, regLNA=B10000
1.6. RSSI=-106, regAFCFEI=B10000, regLNA=B10000
1.7. RSSI=-105, regAFCFEI=B10000, regLNA=B10000
1.8. RSSI=-101, regAFCFEI=B10000, regLNA=B10000
1.9. RSSI=-106, regAFCFEI=B10000, regLNA=B10000
2.0. RSSI=-79, regAFCFEI=B10000, regLNA=B10000
2.1. RSSI=-98, regAFCFEI=B10000, regLNA=B10000
2.2. RSSI=-107, regAFCFEI=B10000, regLNA=B10000
2.3. RSSI=-104, regAFCFEI=B10000, regLNA=B10000
2.4. RSSI=-106, regAFCFEI=B10000, regLNA=B10000
2.5. RSSI=-101, regAFCFEI=B10000, regLNA=B10000
2.6. RSSI=-107, regAFCFEI=B10000, regLNA=B10000
2.7. RSSI=-104, regAFCFEI=B10000, regLNA=B10000
2.8. RSSI=-105, regAFCFEI=B10000, regLNA=B10000
2.9. RSSI=-104, regAFCFEI=B10000, regLNA=B10000
3.0. RSSI=-80, regAFCFEI=B10000, regLNA=B10000
3.1. RSSI=-95, regAFCFEI=B10000, regLNA=B10000
3.2. RSSI=-105, regAFCFEI=B10000, regLNA=B10000
3.3. RSSI=-110, regAFCFEI=B10000, regLNA=B10000
3.4. RSSI=-108, regAFCFEI=B10000, regLNA=B10000
3.5. RSSI=-105, regAFCFEI=B10000, regLNA=B10000
3.6. RSSI=-103, regAFCFEI=B10000, regLNA=B10000
3.7. RSSI=-107, regAFCFEI=B10000, regLNA=B10000
3.8. RSSI=-102, regAFCFEI=B10000, regLNA=B10000
3.9. RSSI=-101, regAFCFEI=B10000, regLNA=B10000
4.0. RSSI=-79, regAFCFEI=B10000, regLNA=B10000
4.1. RSSI=-99, regAFCFEI=B10000, regLNA=B10000
4.2. RSSI=-109, regAFCFEI=B10000, regLNA=B10000
4.3. RSSI=-105, regAFCFEI=B10000, regLNA=B10000
4.4. RSSI=-108, regAFCFEI=B10000, regLNA=B10000
4.5. RSSI=-109, regAFCFEI=B10000, regLNA=B10000
4.6. RSSI=-102, regAFCFEI=B10000, regLNA=B10000
4.7. RSSI=-108, regAFCFEI=B10000, regLNA=B10000
4.8. RSSI=-107, regAFCFEI=B10000, regLNA=B10000
4.9. RSSI=-111, regAFCFEI=B10000, regLNA=B10000
5.0. RSSI=-64, regAFCFEI=B10000, regLNA=B10000
5.1. RSSI=-101, regAFCFEI=B10000, regLNA=B10000
5.2. RSSI=-104, regAFCFEI=B10000, regLNA=B10000
5.3. RSSI=-110, regAFCFEI=B10000, regLNA=B10000
5.4. RSSI=-105, regAFCFEI=B10000, regLNA=B10000
5.5. RSSI=-109, regAFCFEI=B10000, regLNA=B10000
5.6. RSSI=-107, regAFCFEI=B10000, regLNA=B10000
5.7. RSSI=-105, regAFCFEI=B10000, regLNA=B10000
5.8. RSSI=-102, regAFCFEI=B10000, regLNA=B10000
5.9. RSSI=-104, regAFCFEI=B10000, regLNA=B10000



BTW, the above results came from running on the Moteino with the shorted antenna (discussed previously and shown in a photo I posted earlier above).

So, from the look of it, AFC is "finished" whereas FEI is "on-going" according to the datasheet.  So, in this context, does that mean that AFC is effectively "disabled"?  Does it matter that FEI is "on-going"?

Regarding AGC, it looks as though "gain set by the internal AGC loop," according to the datasheet, so I guess that means AGC is  "enabled"?  The only way I see to "disable" AGC is maybe to manually pick some specific LnaGainSelect.  Is that right?   In all the cases, the LNA gain is set to B010, which the datasheet says maps to "G2 = highest gain – 6 dB".


« Last Edit: January 27, 2016, 10:55:15 AM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #59 on: January 27, 2016, 11:23:17 AM »
So, setting LNA manually to G1 yields the following results:

Code: [Select]
1.0. RSSI=-102, regAFCFEI=B10000, regLNA=B1001
1.1. RSSI=-106, regAFCFEI=B10000, regLNA=B1001
1.2. RSSI=-112, regAFCFEI=B10000, regLNA=B1001
1.3. RSSI=-105, regAFCFEI=B10000, regLNA=B1001
1.4. RSSI=-108, regAFCFEI=B10000, regLNA=B1001
1.5. RSSI=-106, regAFCFEI=B10000, regLNA=B1001
1.6. RSSI=-110, regAFCFEI=B10000, regLNA=B1001
1.7. RSSI=-109, regAFCFEI=B10000, regLNA=B1001
1.8. RSSI=-111, regAFCFEI=B10000, regLNA=B1001
1.9. RSSI=-114, regAFCFEI=B10000, regLNA=B1001
2.0. RSSI=-98, regAFCFEI=B10000, regLNA=B1001
2.1. RSSI=-109, regAFCFEI=B10000, regLNA=B1001
2.2. RSSI=-106, regAFCFEI=B10000, regLNA=B1001
2.3. RSSI=-127, regAFCFEI=B10000, regLNA=B1001
2.4. RSSI=-110, regAFCFEI=B10000, regLNA=B1001
2.5. RSSI=-115, regAFCFEI=B10000, regLNA=B1001
2.6. RSSI=-109, regAFCFEI=B10000, regLNA=B1001
2.7. RSSI=-107, regAFCFEI=B10000, regLNA=B1001
2.8. RSSI=-116, regAFCFEI=B10000, regLNA=B1001
2.9. RSSI=-112, regAFCFEI=B10000, regLNA=B1001
3.0. RSSI=-106, regAFCFEI=B10000, regLNA=B1001
3.1. RSSI=-114, regAFCFEI=B10000, regLNA=B1001
3.2. RSSI=-110, regAFCFEI=B10000, regLNA=B1001
3.3. RSSI=-104, regAFCFEI=B10000, regLNA=B1001
3.4. RSSI=-110, regAFCFEI=B10000, regLNA=B1001
3.5. RSSI=-108, regAFCFEI=B10000, regLNA=B1001
3.6. RSSI=-112, regAFCFEI=B10000, regLNA=B1001
3.7. RSSI=-104, regAFCFEI=B10000, regLNA=B1001
3.8. RSSI=-106, regAFCFEI=B10000, regLNA=B1001
3.9. RSSI=-108, regAFCFEI=B10000, regLNA=B1001
4.0. RSSI=-105, regAFCFEI=B10000, regLNA=B1001
4.1. RSSI=-114, regAFCFEI=B10000, regLNA=B1001
4.2. RSSI=-106, regAFCFEI=B10000, regLNA=B1001
4.3. RSSI=-106, regAFCFEI=B10000, regLNA=B1001
4.4. RSSI=-107, regAFCFEI=B10000, regLNA=B1001
4.5. RSSI=-111, regAFCFEI=B10000, regLNA=B1001
4.6. RSSI=-110, regAFCFEI=B10000, regLNA=B1001
4.7. RSSI=-110, regAFCFEI=B10000, regLNA=B1001
4.8. RSSI=-109, regAFCFEI=B10000, regLNA=B1001
4.9. RSSI=-109, regAFCFEI=B10000, regLNA=B1001
5.0. RSSI=-102, regAFCFEI=B10000, regLNA=B1001
5.1. RSSI=-112, regAFCFEI=B10000, regLNA=B1001
5.2. RSSI=-111, regAFCFEI=B10000, regLNA=B1001
5.3. RSSI=-106, regAFCFEI=B10000, regLNA=B1001
5.4. RSSI=-107, regAFCFEI=B10000, regLNA=B1001
5.5. RSSI=-109, regAFCFEI=B10000, regLNA=B1001
5.6. RSSI=-110, regAFCFEI=B10000, regLNA=B1001
5.7. RSSI=-107, regAFCFEI=B10000, regLNA=B1001
5.8. RSSI=-106, regAFCFEI=B10000, regLNA=B1001
5.9. RSSI=-104, regAFCFEI=B10000, regLNA=B1001

Setting LNA manually to G2 (which is what the AGC was selecting) yields:
Code: [Select]
1.0. RSSI=-103, regAFCFEI=B10000, regLNA=B10010
1.1. RSSI=-105, regAFCFEI=B10000, regLNA=B10010
1.2. RSSI=-107, regAFCFEI=B10000, regLNA=B10010
1.3. RSSI=-108, regAFCFEI=B10000, regLNA=B10010
1.4. RSSI=-102, regAFCFEI=B10000, regLNA=B10010
1.5. RSSI=-106, regAFCFEI=B10000, regLNA=B10010
1.6. RSSI=-105, regAFCFEI=B10000, regLNA=B10010
1.7. RSSI=-106, regAFCFEI=B10000, regLNA=B10010
1.8. RSSI=-105, regAFCFEI=B10000, regLNA=B10010
1.9. RSSI=-103, regAFCFEI=B10000, regLNA=B10010
2.0. RSSI=-100, regAFCFEI=B10000, regLNA=B10010
2.1. RSSI=-104, regAFCFEI=B10000, regLNA=B10010
2.2. RSSI=-106, regAFCFEI=B10000, regLNA=B10010
2.3. RSSI=-102, regAFCFEI=B10000, regLNA=B10010
2.4. RSSI=-104, regAFCFEI=B10000, regLNA=B10010
2.5. RSSI=-101, regAFCFEI=B10000, regLNA=B10010
2.6. RSSI=-105, regAFCFEI=B10000, regLNA=B10010
2.7. RSSI=-109, regAFCFEI=B10000, regLNA=B10010
2.8. RSSI=-102, regAFCFEI=B10000, regLNA=B10010
2.9. RSSI=-101, regAFCFEI=B10000, regLNA=B10010
3.0. RSSI=-102, regAFCFEI=B10000, regLNA=B10010
3.1. RSSI=-102, regAFCFEI=B10000, regLNA=B10010
3.2. RSSI=-105, regAFCFEI=B10000, regLNA=B10010
3.3. RSSI=-104, regAFCFEI=B10000, regLNA=B10010
3.4. RSSI=-107, regAFCFEI=B10000, regLNA=B10010
3.5. RSSI=-103, regAFCFEI=B10000, regLNA=B10010
3.6. RSSI=-107, regAFCFEI=B10000, regLNA=B10010
3.7. RSSI=-104, regAFCFEI=B10000, regLNA=B10010
3.8. RSSI=-106, regAFCFEI=B10000, regLNA=B10010
3.9. RSSI=-103, regAFCFEI=B10000, regLNA=B10010
4.0. RSSI=-107, regAFCFEI=B10000, regLNA=B10010
4.1. RSSI=-106, regAFCFEI=B10000, regLNA=B10010
4.2. RSSI=-104, regAFCFEI=B10000, regLNA=B10010
4.3. RSSI=-113, regAFCFEI=B10000, regLNA=B10010
4.4. RSSI=-105, regAFCFEI=B10000, regLNA=B10010
4.5. RSSI=-104, regAFCFEI=B10000, regLNA=B10010
4.6. RSSI=-107, regAFCFEI=B10000, regLNA=B10010
4.7. RSSI=-103, regAFCFEI=B10000, regLNA=B10010
4.8. RSSI=-107, regAFCFEI=B10000, regLNA=B10010
4.9. RSSI=-108, regAFCFEI=B10000, regLNA=B10010
5.0. RSSI=-102, regAFCFEI=B10000, regLNA=B10010
5.1. RSSI=-101, regAFCFEI=B10000, regLNA=B10010
5.2. RSSI=-101, regAFCFEI=B10000, regLNA=B10010
5.3. RSSI=-104, regAFCFEI=B10000, regLNA=B10010
5.4. RSSI=-105, regAFCFEI=B10000, regLNA=B10010
5.5. RSSI=-102, regAFCFEI=B10000, regLNA=B10010
5.6. RSSI=-105, regAFCFEI=B10000, regLNA=B10010
5.7. RSSI=-101, regAFCFEI=B10000, regLNA=B10010
5.8. RSSI=-100, regAFCFEI=B10000, regLNA=B10010
5.9. RSSI=-109, regAFCFEI=B10000, regLNA=B10010

Setting LNA manually to G6 (which is what the AGC was selecting) yields:
Code: [Select]
1.0. RSSI=-66, regAFCFEI=B10000, regLNA=B110110
1.1. RSSI=-70, regAFCFEI=B10000, regLNA=B110110
1.2. RSSI=-65, regAFCFEI=B10000, regLNA=B110110
1.3. RSSI=-63, regAFCFEI=B10000, regLNA=B110110
1.4. RSSI=-65, regAFCFEI=B10000, regLNA=B110110
1.5. RSSI=-65, regAFCFEI=B10000, regLNA=B110110
1.6. RSSI=-71, regAFCFEI=B10000, regLNA=B110110
1.7. RSSI=-67, regAFCFEI=B10000, regLNA=B110110
1.8. RSSI=-68, regAFCFEI=B10000, regLNA=B110110
1.9. RSSI=-64, regAFCFEI=B10000, regLNA=B110110
2.0. RSSI=-62, regAFCFEI=B10000, regLNA=B110110
2.1. RSSI=-63, regAFCFEI=B10000, regLNA=B110110
2.2. RSSI=-63, regAFCFEI=B10000, regLNA=B110110
2.3. RSSI=-67, regAFCFEI=B10000, regLNA=B110110
2.4. RSSI=-70, regAFCFEI=B10000, regLNA=B110110
2.5. RSSI=-68, regAFCFEI=B10000, regLNA=B110110
2.6. RSSI=-63, regAFCFEI=B10000, regLNA=B110110
2.7. RSSI=-72, regAFCFEI=B10000, regLNA=B110110
2.8. RSSI=-70, regAFCFEI=B10000, regLNA=B110110
2.9. RSSI=-67, regAFCFEI=B10000, regLNA=B110110
3.0. RSSI=-62, regAFCFEI=B10000, regLNA=B110110
3.1. RSSI=-72, regAFCFEI=B10000, regLNA=B110110
3.2. RSSI=-65, regAFCFEI=B10000, regLNA=B110110
3.3. RSSI=-69, regAFCFEI=B10000, regLNA=B110110
3.4. RSSI=-66, regAFCFEI=B10000, regLNA=B110110
3.5. RSSI=-65, regAFCFEI=B10000, regLNA=B110110
3.6. RSSI=-70, regAFCFEI=B10000, regLNA=B110110
3.7. RSSI=-62, regAFCFEI=B10000, regLNA=B110110
3.8. RSSI=-65, regAFCFEI=B10000, regLNA=B110110
3.9. RSSI=-63, regAFCFEI=B10000, regLNA=B110110
4.0. RSSI=-63, regAFCFEI=B10000, regLNA=B110110
4.1. RSSI=-60, regAFCFEI=B10000, regLNA=B110110
4.2. RSSI=-69, regAFCFEI=B10000, regLNA=B110110
4.3. RSSI=-68, regAFCFEI=B10000, regLNA=B110110
4.4. RSSI=-72, regAFCFEI=B10000, regLNA=B110110
4.5. RSSI=-68, regAFCFEI=B10000, regLNA=B110110
4.6. RSSI=-69, regAFCFEI=B10000, regLNA=B110110
4.7. RSSI=-75, regAFCFEI=B10000, regLNA=B110110
4.8. RSSI=-65, regAFCFEI=B10000, regLNA=B110110
4.9. RSSI=-74, regAFCFEI=B10000, regLNA=B110110
5.0. RSSI=-66, regAFCFEI=B10000, regLNA=B110110
5.1. RSSI=-66, regAFCFEI=B10000, regLNA=B110110
5.2. RSSI=-71, regAFCFEI=B10000, regLNA=B110110
5.3. RSSI=-64, regAFCFEI=B10000, regLNA=B110110
5.4. RSSI=-68, regAFCFEI=B10000, regLNA=B110110
5.5. RSSI=-67, regAFCFEI=B10000, regLNA=B110110
5.6. RSSI=-66, regAFCFEI=B10000, regLNA=B110110
5.7. RSSI=-66, regAFCFEI=B10000, regLNA=B110110
5.8. RSSI=-68, regAFCFEI=B10000, regLNA=B110110
5.9. RSSI=-69, regAFCFEI=B10000, regLNA=B110110

So, given the difference between manually setting LNA to G2 versus letting AGC set the LNA to G2, the manual setting seems less anomalous.

Theoretically, with a shorted antenna, all the RSSI values should be -127, at least ideally.  Isn't that right?  Looking at the above results, the only time I get even one measurement with RSSI=-127 is when LNA is set to G1.

Bottom line: when just measuring ambient RSSI, is it best to manually set LNA to G1?

On the other hand, suppose you determine empirically that when receiving packets from a particular RFM69 Moteino, the AGC is generally using a gain of G2.  In that case, maybe setting LNA manually to G2 would be the more relevant choice, because then you'd be measuring the background RSSI at the LNA level that's most relevant to receiving packets from that particular RFM69 Moteino.  Isn't that right?

I'm just feeling my way through the dark here, so any and all comments/suggestions/help/guidance would be more than welcome.

Not to overcomplicate the discussion, but does DC cancellation figure into this at all?  Quoting the datasheet: "DC cancellation is required in zero-IF architecture transceivers to remove any DC offset generated through self-reception."  What kind of "self-reception" is it referring to?  i.e. Is that "self-reception" the result of the transceiver's own transmission, or is it "self-reception" of the noise created by the RFM69 in normal operation? 

The datasheet also says, "It is advised to adjust the DCC setting while monitoring the receiver sensitivity."  How does one even do that?  I've searched this forum and haven't found any meaningful postings about DCC.
« Last Edit: January 27, 2016, 12:32:39 PM by WhiteHare »