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

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Real time RSSI measurement broken RFM69CW?
« on: December 12, 2015, 05:49:59 AM »
I've been struggling to read the RSSI in real time using the RssiStart and RssiDone bits in the RssiConfig register. It appears that the RssiValue register does not update when the receiver has triggered. Interesingly the sx1231 datasheet, which is for silicon rev 2.3, states: "RssiStart command and RssiDone flags are not usable when DAGC is turned on, see section 3.5.4"., yet this statement is missing from the sx1231h datasheet which is for silicon rev 2.4. Both state that the RSSI has to be above the threshold in RssiThresh register.

I've tried disabling DAGC and just about every other combination but cannot get this mechanism to work. I have a workaround which is a bit of a hack but appears to work. This sets the threshold to way below the noise floor so that it continually triggers a new RSSI interrupt which in turn updates the RssiValue:

set RssiThresh to 0xFF (well below noise floor)
enable RX mode
loop:
      wait for RSSI interrupt
      read RssiValue register
      restart RX receiver (RestartRx bit in PacketConfig2 register)
goto loop

It is possible that they tried to fix the DAGC dependence when up-reving the silicon but broke it. I think this may have implications for RadioHead if using CSMA, I note that the rssiRead() function in the RadioHead library has a note that the start/done mechanism hangs forever, so it just returns the RssiValue register instead.

Mark.
« Last Edit: December 12, 2015, 06:03:59 AM by perky »

kobuki

  • Sr. Member
  • ****
  • Posts: 289
Re: Real time RSSI measurement broken RFM69CW?
« Reply #1 on: December 20, 2015, 02:21:30 PM »
While doing experiments in OOK mode of the RFM69, I struggled with the RSSI readouts for quite some time. I was successful, however, using continuous mode and appropriately set thresholds. I've no idea what functionality you're after, so this might not be a solution for you, but please see this post. I can post the code I used for dumping, it's not on GitHub.

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #2 on: December 21, 2015, 09:54:59 AM »
Thanks for this. Unfortunately I'm not using OOK mode, although I could program it to be so temporarily for the duration of RSSI measurements (e.g. for CSMA). My main reason for doing this was to check whether a particular frequency is 'in use', but it's quite hard to get a feel for that given some devices will be bursty and transmit at random times possibly many hours apart. Anyway I'm glad you were able to do it.
Mark. 

kobuki

  • Sr. Member
  • ****
  • Posts: 289
Re: Real time RSSI measurement broken RFM69CW?
« Reply #3 on: December 21, 2015, 10:05:22 AM »
You need this in your sketch to optimise frequency domain usage? Otherwise I think that an SDR stick with a scanner app would be more adequate for interference hunting...

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #4 on: December 21, 2015, 11:00:43 AM »
The idea was to look for free channels for a single frequency system to choose. I've actually got an Rfexplorer (low cost spectrum analyser) that can be of help, but as you point out you really need time domain analysis too.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #5 on: January 16, 2016, 12:07:10 PM »
@Perky RSSIstart and RSSIdone are not even mentioned in the SX1232 nor the SX1276  datasheets.  I presume both were built on the earlier work.  Mostly Semtech seems to have added.  This is the first deletion I've noticed.  Hmm....

Thanks for marking the trail and posting the workaround you found.   :)
« Last Edit: January 16, 2016, 12:26:15 PM by WhiteHare »

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #6 on: January 17, 2016, 06:56:40 PM »
Interesting find, maybe it never worked at all. I was using FSK in packet mode, so didn't try continuous mode or OOP.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #7 on: January 17, 2016, 08:29:58 PM »
@Perky I crudely implemented your workaround method, using Felix's library, here:  https://lowpowerlab.com/forum/index.php/topic,1538.msg10792.html#msg10792
and, despite being a quick and dirty hack that I have no doubt could be improved upon, it seems to work.   :) 

It calls radio.readRSSI(), but if you were to call radio.readRSSI(true) instead, then Felix's code would actually invoke rssiStart and wait for rssiDone.  I did try that, and although it doesn't hang forever, it took a few orders of magnitude longer to return a value than just radio.readRSSI().

emjay

  • Full Member
  • ***
  • Posts: 119
  • Country: nl
Re: Real time RSSI measurement broken RFM69CW?
« Reply #8 on: January 18, 2016, 08:39:48 AM »
@WhiteHare,

How do we know that strobing an internal register semi-continuously without any formal handshake mechanism around that will yield valid values?

There was this reference cited earlier that clearly stated the RSSI register was used as internal workspace by the module state machine in OOK - I'd be cautious the same was true in FSK.
« Last Edit: January 18, 2016, 08:42:11 AM by emjay »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #9 on: January 18, 2016, 11:57:00 AM »
@emjay Aside from "be cautious," what do you recommend?

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #10 on: January 18, 2016, 12:43:29 PM »
@WhiteHare: Nice one, good to see an implementation of it (BTW I don't claim that it was my idea, there are other posts that do something similar :) )

@emjay: There is a formal handshake. When put into receive mode the RSSI will trigger if above the threshold (which is set to below the noise floor, so will trigger immediately). The RSSI interrupt would then trigger allowing the RSSI to be read, this condition is latched until the receiver is either taken out of RX mode or is restarted. This in turn will clear the RSSI interrupt. So in theory you should always read a valid RSSI measurement.

Mark.

emjay

  • Full Member
  • ***
  • Posts: 119
  • Country: nl
Re: Real time RSSI measurement broken RFM69CW?
« Reply #11 on: January 18, 2016, 12:51:38 PM »
@perky,

Agreed. But is that what looping on radio.readRSSI() actually does?

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #12 on: January 18, 2016, 12:56:47 PM »
Good question, I haven't checked. It should, as the restart command is essential in maintaining the handshake. I'll take a look.
Mark.

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #13 on: January 18, 2016, 01:16:59 PM »
It appears that  radio.readRSSI() simply returns the RSSI register.

@WhiteHare: I think you need to implement the loop as shown in the OP, complete with polling for the RSSI interrupt and issuing a restart once the RSSI register has been read. You could either do that by creating a new function call, or with some code that implements that sequence.

Mark.
« Last Edit: January 18, 2016, 01:22:39 PM by perky »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #14 on: January 18, 2016, 01:41:45 PM »
All I can say is that, as implemented, it produces a stream of plausible values.  If I bring a transmitter close to it, they become less negative.  I tried tracking the maximum when bringing a transmitter closer, and it matched what I expected.  So, basically, it looks like a duck, and it quacks like a duck.  Does that make it a duck?  There's only so much I can validate using tools that are only a little more advanced than stone knives and bear skins.

I don't have any guarantees or proofs to offer emjay.  It's simply an early result, so though I'm hoping it either is or leads to something useful, at the moment I can't say with certainty.
« Last Edit: January 19, 2016, 03:41:37 PM by WhiteHare »

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #15 on: January 18, 2016, 06:43:55 PM »
Can I ask what modes the receiver and transmitters are in during these tests? E.g. FSK, packet mode, fixed or variable length? Also are you sending legitimate packets that normally would have been received (in other words would it normally trigger a sync address match and payload ready), or are they designed to not produce a payload ready by using a different bit rate or sync word?

I'm confused as to how the receiver might be re-triggering a new RSSI sample event if the receiver is not explicitly being taken out of RX mode or being re-started. I thought the RSSI interrupt was the indication that a new RSSI value is available in the RSSI register, but that interrupt is not cleared down until it is taken out of RX mode or re-started.

Possibly some other condition is causing a restart (maybe a FIFO clear event), for example if you were using fixed packet length and didn't clear the FIFO by reading it out this might cause a reset condition which could possibly cause an RSSI re-trigger.

Mark.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #16 on: January 19, 2016, 03:15:18 PM »
Can I ask what modes the receiver and transmitters are in during these tests? E.g. FSK, packet mode, fixed or variable length? Also are you sending legitimate packets that normally would have been received (in other words would it normally trigger a sync address match and payload ready), or are they designed to not produce a payload ready by using a different bit rate or sync word?


You're asking the right questions.  I only tried it with the transmitter and receiver parameters set the same.  A better test would be to set the bitrate of the transmitter to something else, so that the receiver would only see the Tx power but not be able to decode the packet.  I haven't run that test yet.

Here is the gateway code that I ran most recently, which tracks the maximum RSSI it measures:
Code: [Select]
// Sample RFM69 receiver/gateway sketch, with ACK and optional encryption
// Passes through any wireless received messages to the serial port & responds to ACKs
// It also looks for an onboard FLASH chip, if present
// Library and code by Felix Rusu - felix@lowpowerlab.com
// Get the RFM69 and SPIFlash library at: https://github.com/LowPowerLab/

#include <RFM69.h>    //get it here: https://www.github.com/lowpowerlab/rfm69
#include <SPI.h>
#include <SPIFlash.h> //get it here: https://www.github.com/lowpowerlab/spiflash
#include <RFM69registers.h>

#define NODEID        1    //unique for each node on same network
#define NETWORKID     100  //the same on all nodes that talk to each other
//Match frequency to the hardware version of the radio on your Moteino (uncomment one):
//#define FREQUENCY     RF69_433MHZ
//#define FREQUENCY     RF69_868MHZ
#define FREQUENCY     RF69_915MHZ
#define ENCRYPTKEY    "sampleEncryptKey" //exactly the same 16 characters/bytes on all nodes!
#define IS_RFM69HW    //uncomment only for RFM69HW! Leave out if you have RFM69W!
#define SERIAL_BAUD   250000

#ifdef __AVR_ATmega1284P__
  #define LED           15 // Moteino MEGAs have LEDs on D15
  #define FLASH_SS      23 // and FLASH SS on D23
#else
  #define LED           9 // Moteinos have LEDs on D9
  #define FLASH_SS      8 // and FLASH SS on D8
#endif

RFM69 radio;
SPIFlash flash(FLASH_SS, 0xEF30); //EF30 for 4mbit  Windbond chip (W25X40CL)
bool promiscuousMode = false; //set to 'true' to sniff all packets on the same network

void setup() {
  Serial.begin(SERIAL_BAUD);
  delay(10);
  radio.initialize(FREQUENCY,NODEID,NETWORKID);
#ifdef IS_RFM69HW
  radio.setHighPower(); //only for RFM69HW!
#endif
  radio.encrypt(ENCRYPTKEY);
  radio.promiscuous(promiscuousMode);
  //radio.setFrequency(919000000);
  radio.writeReg(REG_OPMODE, (radio.readReg(REG_OPMODE) & 0xE3) | RF_OPMODE_STANDBY);  //set standby-mode
  radio.writeReg(REG_RSSITHRESH, 0xFF);  //set RSSI threshhold as low as possible
  radio.writeReg(REG_OPMODE, (radio.readReg(REG_OPMODE) & 0xE3) | RF_OPMODE_RECEIVER);  //set standby-mode

 
  char buff[50];
  sprintf(buff, "\nListening at %d Mhz...", FREQUENCY==RF69_433MHZ ? 433 : FREQUENCY==RF69_868MHZ ? 868 : 915);
  Serial.println(buff);
  if (flash.initialize())
  {
    Serial.print("SPI Flash Init OK. Unique MAC = [");
    flash.readUniqueId();
    for (byte i=0;i<8;i++)
    {
      Serial.print(flash.UNIQUEID[i], HEX);
      if (i!=8) Serial.print(':');
    }
    Serial.println(']');
   
    //alternative way to read it:
    //byte* MAC = flash.readUniqueId();
    //for (byte i=0;i<8;i++)
    //{
    //  Serial.print(MAC[i], HEX);
    //  Serial.print(' ');
    //}
   
  }
  else
    Serial.println("SPI Flash Init FAIL! (is chip present?)");
}

byte ackCount=0;
uint32_t packetCount = 0;
long loopCount=0;
int rssi;
int maxRSSI= (-125);
void loop() {
  radio.writeReg(REG_OPMODE, (radio.readReg(REG_OPMODE) & 0xE3) | RF_OPMODE_STANDBY);  //set standby-mode
  radio.writeReg(REG_RSSITHRESH, 0xFF);  //set RSSI threshhold as low as possible
  radio.writeReg(REG_OPMODE, (radio.readReg(REG_OPMODE) & 0xE3) | RF_OPMODE_RECEIVER);  //set standby-mode

  loopCount++;
  rssi = radio.readRSSI();
  if (rssi > maxRSSI) {
    maxRSSI = rssi;
  }
 
  if ((loopCount%1)==0) {
    Serial.print(loopCount);
    Serial.print(". ");Serial.print(radio.readRSSI());Serial.print(" ");
    Serial.println(maxRSSI);
    //Serial.flush(); 
  }
}

void Blink(byte PIN, int DELAY_MS)
{
  pinMode(PIN, OUTPUT);
  digitalWrite(PIN,HIGH);
  delay(DELAY_MS);
  digitalWrite(PIN,LOW);
}

« Last Edit: January 19, 2016, 03:22:45 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #17 on: January 19, 2016, 03:15:45 PM »
Here is the transmitter code (run on a separate moteino):
Code: [Select]
// Sample RFM69 sender/node sketch, with ACK and optional encryption
// Sends periodic messages of increasing length to gateway (id=1)
// It also looks for an onboard FLASH chip, if present
// Library and code by Felix Rusu - felix@lowpowerlab.com
// Get the RFM69 and SPIFlash library at: https://github.com/LowPowerLab/

#include <RFM69.h>    //get it here: https://www.github.com/lowpowerlab/rfm69
#include <SPI.h>
#include <SPIFlash.h> //get it here: https://www.github.com/lowpowerlab/spiflash

#define NODEID        2    //unique for each node on same network
#define NETWORKID     100  //the same on all nodes that talk to each other
#define GATEWAYID     1
//Match frequency to the hardware version of the radio on your Moteino (uncomment one):
//#define FREQUENCY   RF69_433MHZ
//#define FREQUENCY   RF69_868MHZ
#define FREQUENCY     RF69_915MHZ
#define ENCRYPTKEY    "sampleEncryptKey" //exactly the same 16 characters/bytes on all nodes!
#define IS_RFM69HW    //uncomment only for RFM69HW! Leave out if you have RFM69W!
#ifdef __AVR_ATmega1284P__
  #define LED           15 // Moteino MEGAs have LEDs on D15
  #define FLASH_SS      23 // and FLASH SS on D23
#else
  #define LED           9 // Moteinos have LEDs on D9
  #define FLASH_SS      8 // and FLASH SS on D8
#endif

#define SERIAL_BAUD   115200

int TRANSMITPERIOD = 150; //transmit a packet to gateway so often (in ms)
char payload[] = "123 ABCDEFGHIJKLMNOPQRSTUVWXYZ";
char buff[20];
byte sendSize=0;
boolean requestACK = false;
SPIFlash flash(FLASH_SS, 0xEF30); //EF30 for 4mbit  Windbond chip (W25X40CL)
RFM69 radio;

void setup() {
  Serial.begin(SERIAL_BAUD);
  radio.initialize(FREQUENCY,NODEID,NETWORKID);
#ifdef IS_RFM69HW
  radio.setHighPower(); //uncomment only for RFM69HW!
#endif
  radio.encrypt(ENCRYPTKEY);
  //radio.setFrequency(919000000); //set frequency to some custom frequency
  char buff[50];
  sprintf(buff, "\nTransmitting at %d Mhz...", FREQUENCY==RF69_433MHZ ? 433 : FREQUENCY==RF69_868MHZ ? 868 : 915);
  Serial.println(buff);
 
  if (flash.initialize())
  {
    Serial.print("SPI Flash Init OK ... UniqueID (MAC): ");
    flash.readUniqueId();
    for (byte i=0;i<8;i++)
    {
      Serial.print(flash.UNIQUEID[i], HEX);
      Serial.print(' ');
    }
    Serial.println();
  }
  else
    Serial.println("SPI Flash Init FAIL! (is chip present?)");
}

long lastPeriod = 0;
void loop() {
  //process any serial input
  if (Serial.available() > 0)
  {
    char input = Serial.read();
    if (input >= 48 && input <= 57) //[0,9]
    {
      TRANSMITPERIOD = 100 * (input-48);
      if (TRANSMITPERIOD == 0) TRANSMITPERIOD = 1000;
      Serial.print("\nChanging delay to ");
      Serial.print(TRANSMITPERIOD);
      Serial.println("ms\n");
    }

    if (input == 'r') //d=dump register values
      radio.readAllRegs();
    //if (input == 'E') //E=enable encryption
    //  radio.encrypt(KEY);
    //if (input == 'e') //e=disable encryption
    //  radio.encrypt(null);

    if (input == 'd') //d=dump flash area
    {
      Serial.println("Flash content:");
      uint16_t counter = 0;

      Serial.print("0-256: ");
      while(counter<=256){
        Serial.print(flash.readByte(counter++), HEX);
        Serial.print('.');
      }
      while(flash.busy());
      Serial.println();
    }
    if (input == 'e')
    {
      Serial.print("Erasing Flash chip ... ");
      flash.chipErase();
      while(flash.busy());
      Serial.println("DONE");
    }
    if (input == 'i')
    {
      Serial.print("DeviceID: ");
      word jedecid = flash.readDeviceId();
      Serial.println(jedecid, HEX);
    }
  }

  //check for any received packets
  if (radio.receiveDone())
  {
    Serial.print('[');Serial.print(radio.SENDERID, DEC);Serial.print("] ");
    for (byte i = 0; i < radio.DATALEN; i++)
      Serial.print((char)radio.DATA[i]);
    Serial.print("   [RX_RSSI:");Serial.print(radio.RSSI);Serial.print("]");

    if (radio.ACKRequested())
    {
      radio.sendACK();
      Serial.print(" - ACK sent");
    }
    Blink(LED,3);
    Serial.println();
  }

  int currPeriod = millis()/TRANSMITPERIOD;
  if (currPeriod != lastPeriod)
  {
    lastPeriod=currPeriod;
   
    //send FLASH id
    if(sendSize==0)
    {
      sprintf(buff, "FLASH_MEM_ID:0x%X", flash.readDeviceId());
      byte buffLen=strlen(buff);
      if (radio.sendWithRetry(GATEWAYID, buff, buffLen))
        Serial.print(" ok!");
      else Serial.print(" nothing...");
      //sendSize = (sendSize + 1) % 31;
    }
    else
    {
      Serial.print("Sending[");
      Serial.print(sendSize);
      Serial.print("]: ");
      for(byte i = 0; i < sendSize; i++)
        Serial.print((char)payload[i]);
 
      if (radio.sendWithRetry(GATEWAYID, payload, sendSize))
       Serial.print(" ok!");
      else Serial.print(" nothing...");
    }
    sendSize = (sendSize + 1) % 31;
    Serial.println();
    Blink(LED,3);
  }
}

void Blink(byte PIN, int DELAY_MS)
{
  pinMode(PIN, OUTPUT);
  digitalWrite(PIN,HIGH);
  delay(DELAY_MS);
  digitalWrite(PIN,LOW);
}

One odd thing I did notice is that when I set the modulus of how many receives to do before printing a result to a higher number, I expected it would more quickly pick up the transmitter and record its maximum, since it wouldn't be slowed down by doing all the serial printouts, but it actually seemed to be the opposite of that.  So, maybe there needs to be some settle time explicitly added in between adjustments to the radio.
« Last Edit: January 19, 2016, 03:18:44 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #18 on: January 19, 2016, 11:49:16 PM »
I cleaned up the code a little, and it runs even better now.   :)

Also, I ran the test with the transmitter (node Moteino) running at 1200bps, and the receiver (gateway Moteino) has its bitrate set at 300kbps.  It functions the same, so it is further evidence that it is reading the RSSI and not just the RSSI on packets that it decodes.  In fact, with the bitrates set so differently, it shouldn't be decoding any valid packets at all.

Here's Version2 of the transmitter (node Moteino) code:
Code: [Select]
// Sample RFM69 sender/node sketch, with ACK and optional encryption
// Sends periodic messages of increasing length to gateway (id=1)
// It also looks for an onboard FLASH chip, if present
// Library and code by Felix Rusu - felix@lowpowerlab.com
// Get the RFM69 and SPIFlash library at: https://github.com/LowPowerLab/

#include <RFM69.h>    //get it here: https://www.github.com/lowpowerlab/rfm69
#include <SPI.h>
#include <SPIFlash.h> //get it here: https://www.github.com/lowpowerlab/spiflash
#include <RFM69registers.h>

#define NODEID        2    //unique for each node on same network
#define NETWORKID     100  //the same on all nodes that talk to each other
#define GATEWAYID     1
//Match frequency to the hardware version of the radio on your Moteino (uncomment one):
//#define FREQUENCY   RF69_433MHZ
//#define FREQUENCY   RF69_868MHZ
#define FREQUENCY     RF69_915MHZ
#define ENCRYPTKEY    "sampleEncryptKey" //exactly the same 16 characters/bytes on all nodes!
#define IS_RFM69HW    //uncomment only for RFM69HW! Leave out if you have RFM69W!
#ifdef __AVR_ATmega1284P__
  #define LED           15 // Moteino MEGAs have LEDs on D15
  #define FLASH_SS      23 // and FLASH SS on D23
#else
  #define LED           9 // Moteinos have LEDs on D9
  #define FLASH_SS      8 // and FLASH SS on D8
#endif

#define SERIAL_BAUD   115200

int TRANSMITPERIOD = 150; //transmit a packet to gateway so often (in ms)
char payload[] = "123 ABCDEFGHIJKLMNOPQRSTUVWXYZ";
char buff[20];
byte sendSize=0;
boolean requestACK = false;
SPIFlash flash(FLASH_SS, 0xEF30); //EF30 for 4mbit  Windbond chip (W25X40CL)
RFM69 radio;

void setup() {
  Serial.begin(SERIAL_BAUD);
  radio.initialize(FREQUENCY,NODEID,NETWORKID);
#ifdef IS_RFM69HW
  radio.setHighPower(); //uncomment only for RFM69HW!
#endif
  radio.encrypt(ENCRYPTKEY);
  //radio.setFrequency(919000000); //set frequency to some custom frequency
  radio.writeReg(REG_BITRATEMSB, RF_BITRATEMSB_1200);  //set MSB bitrate to 1200
  radio.writeReg(REG_BITRATELSB, RF_BITRATELSB_1200);  //set LSB bitrate to 1200
  Serial.println(F("Bitrate set to 1200"));
 
  char buff[50];
  sprintf(buff, "\nTransmitting at %d Mhz...", FREQUENCY==RF69_433MHZ ? 433 : FREQUENCY==RF69_868MHZ ? 868 : 915);
  Serial.println(buff);
 
  if (flash.initialize())
  {
    Serial.print("SPI Flash Init OK ... UniqueID (MAC): ");
    flash.readUniqueId();
    for (byte i=0;i<8;i++)
    {
      Serial.print(flash.UNIQUEID[i], HEX);
      Serial.print(' ');
    }
    Serial.println();
  }
  else
    Serial.println("SPI Flash Init FAIL! (is chip present?)");
}

long lastPeriod = 0;
void loop() {
  //process any serial input
  if (Serial.available() > 0)
  {
    char input = Serial.read();
    if (input >= 48 && input <= 57) //[0,9]
    {
      TRANSMITPERIOD = 100 * (input-48);
      if (TRANSMITPERIOD == 0) TRANSMITPERIOD = 1000;
      Serial.print("\nChanging delay to ");
      Serial.print(TRANSMITPERIOD);
      Serial.println("ms\n");
    }

    if (input == 'r') //d=dump register values
      radio.readAllRegs();
    //if (input == 'E') //E=enable encryption
    //  radio.encrypt(KEY);
    //if (input == 'e') //e=disable encryption
    //  radio.encrypt(null);

    if (input == 'd') //d=dump flash area
    {
      Serial.println("Flash content:");
      uint16_t counter = 0;

      Serial.print("0-256: ");
      while(counter<=256){
        Serial.print(flash.readByte(counter++), HEX);
        Serial.print('.');
      }
      while(flash.busy());
      Serial.println();
    }
    if (input == 'e')
    {
      Serial.print("Erasing Flash chip ... ");
      flash.chipErase();
      while(flash.busy());
      Serial.println("DONE");
    }
    if (input == 'i')
    {
      Serial.print("DeviceID: ");
      word jedecid = flash.readDeviceId();
      Serial.println(jedecid, HEX);
    }
  }

  //check for any received packets
  if (radio.receiveDone())
  {
    Serial.print('[');Serial.print(radio.SENDERID, DEC);Serial.print("] ");
    for (byte i = 0; i < radio.DATALEN; i++)
      Serial.print((char)radio.DATA[i]);
    Serial.print("   [RX_RSSI:");Serial.print(radio.RSSI);Serial.print("]");

    if (radio.ACKRequested())
    {
      radio.sendACK();
      Serial.print(" - ACK sent");
    }
    Blink(LED,3);
    Serial.println();
  }

  int currPeriod = millis()/TRANSMITPERIOD;
  if (currPeriod != lastPeriod)
  {
    lastPeriod=currPeriod;
   
    //send FLASH id
    if(sendSize==0)
    {
      sprintf(buff, "FLASH_MEM_ID:0x%X", flash.readDeviceId());
      byte buffLen=strlen(buff);
      if (radio.sendWithRetry(GATEWAYID, buff, buffLen))
        Serial.print(" ok!");
      else Serial.print(" nothing...");
      //sendSize = (sendSize + 1) % 31;
    }
    else
    {
      Serial.print("Sending[");
      Serial.print(sendSize);
      Serial.print("]: ");
      for(byte i = 0; i < sendSize; i++)
        Serial.print((char)payload[i]);
 
      if (radio.sendWithRetry(GATEWAYID, payload, sendSize))
       Serial.print(" ok!");
      else Serial.print(" nothing...");
    }
    sendSize = (sendSize + 1) % 31;
    Serial.println();
    Blink(LED,3);
  }
}

void Blink(byte PIN, int DELAY_MS)
{
  pinMode(PIN, OUTPUT);
  digitalWrite(PIN,HIGH);
  delay(DELAY_MS);
  digitalWrite(PIN,LOW);
}
« Last Edit: January 20, 2016, 12:10:41 AM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #19 on: January 19, 2016, 11:51:21 PM »
Here's version2 of the receive (Moteino gateway) code:
Code: [Select]
// Sample RFM69 receiver/gateway sketch, with ACK and optional encryption
// Passes through any wireless received messages to the serial port & responds to ACKs
// It also looks for an onboard FLASH chip, if present
// Library and code by Felix Rusu - felix@lowpowerlab.com
// Get the RFM69 and SPIFlash library at: https://github.com/LowPowerLab/

#include <RFM69.h>    //get it here: https://www.github.com/lowpowerlab/rfm69
#include <SPI.h>
#include <SPIFlash.h> //get it here: https://www.github.com/lowpowerlab/spiflash
#include <RFM69registers.h>

#define NODEID        1    //unique for each node on same network
#define NETWORKID     100  //the same on all nodes that talk to each other
//Match frequency to the hardware version of the radio on your Moteino (uncomment one):
//#define FREQUENCY     RF69_433MHZ
//#define FREQUENCY     RF69_868MHZ
#define FREQUENCY     RF69_915MHZ
#define ENCRYPTKEY    "sampleEncryptKey" //exactly the same 16 characters/bytes on all nodes!
#define IS_RFM69HW    //uncomment only for RFM69HW! Leave out if you have RFM69W!
#define SERIAL_BAUD   250000

#ifdef __AVR_ATmega1284P__
  #define LED           15 // Moteino MEGAs have LEDs on D15
  #define FLASH_SS      23 // and FLASH SS on D23
#else
  #define LED           9 // Moteinos have LEDs on D9
  #define FLASH_SS      8 // and FLASH SS on D8
#endif

RFM69 radio;
SPIFlash flash(FLASH_SS, 0xEF30); //EF30 for 4mbit  Windbond chip (W25X40CL)
bool promiscuousMode = false; //set to 'true' to sniff all packets on the same network

void setup() {
  Serial.begin(SERIAL_BAUD);
  delay(10);
  radio.initialize(FREQUENCY,NODEID,NETWORKID);
#ifdef IS_RFM69HW
  radio.setHighPower(); //only for RFM69HW!
#endif
  radio.encrypt(ENCRYPTKEY);
  radio.promiscuous(promiscuousMode);
  //radio.setFrequency(919000000);
  //radio.writeReg(REG_OPMODE, (radio.readReg(REG_OPMODE) & 0xE3) | RF_OPMODE_STANDBY);  //set standby-mode
  //radio.writeReg(REG_RSSITHRESH, 0xFF);  //set RSSI threshhold as low as possible
  //radio.writeReg(REG_OPMODE, (radio.readReg(REG_OPMODE) & 0xE3) | RF_OPMODE_RECEIVER);  //set standby-mode
  radio.writeReg(REG_BITRATEMSB, RF_BITRATEMSB_300000);  //set MSB bitrate to 300Kbps
  radio.writeReg(REG_BITRATELSB, RF_BITRATELSB_300000);  //set LSB bitrate to 300Kbps
  Serial.println(F("Bitrate set to 300Kbps."));
 
  char buff[50];
  sprintf(buff, "\nListening at %d Mhz...", FREQUENCY==RF69_433MHZ ? 433 : FREQUENCY==RF69_868MHZ ? 868 : 915);
  Serial.println(buff);
  if (flash.initialize())
  {
    Serial.print("SPI Flash Init OK. Unique MAC = [");
    flash.readUniqueId();
    for (byte i=0;i<8;i++)
    {
      Serial.print(flash.UNIQUEID[i], HEX);
      if (i!=8) Serial.print(':');
    }
    Serial.println(']');
   
    //alternative way to read it:
    //byte* MAC = flash.readUniqueId();
    //for (byte i=0;i<8;i++)
    //{
    //  Serial.print(MAC[i], HEX);
    //  Serial.print(' ');
    //}
   
  }
  else
    Serial.println("SPI Flash Init FAIL! (is chip present?)");
}

byte ackCount=0;
uint32_t packetCount = 0;
long loopCount=0;
int theRSSI;
int maxRSSI= (-125);
void loop() {
  radio.writeReg(REG_OPMODE, (radio.readReg(REG_OPMODE) & 0xE3) | RF_OPMODE_STANDBY);  //set standby-mode
  radio.writeReg(REG_RSSITHRESH, 0xFF);  //set RSSI threshhold as low as possible
  radio.writeReg(REG_OPMODE, (radio.readReg(REG_OPMODE) & 0xE3) | RF_OPMODE_RECEIVER);  //set standby-mode

  loopCount++;
  theRSSI = radio.readRSSI();
  if ((theRSSI > maxRSSI)) {
    maxRSSI = theRSSI;
  }
 
  if ((loopCount%1)==0) { //can change to %100 to have one printline per 100 RSSI measurements
    Serial.print(loopCount);
    Serial.print(F(". RSSI="));Serial.print(theRSSI);Serial.print(", maxRSSI=");
    Serial.println(maxRSSI);
    //Serial.flush(); 
  }
}

void Blink(byte PIN, int DELAY_MS)
{
  pinMode(PIN, OUTPUT);
  digitalWrite(PIN,HIGH);
  delay(DELAY_MS);
  digitalWrite(PIN,LOW);
}

I start the test by running just the gateway (transmitter is off).  When I switch on the transmitter, the max RSSI changes pretty much immediately.  As I move the transmitter closer to the receiver, the max RSSI changes in the way that you expect that it would.

It would be great if someone besides just me would try running it and then post how it went.  I've given the complete sketches.  All you need to replicate the experiment are two RFM69 moteinos and the Version2 code that I've provided here.  It should only take a minute or two to load it up and try it.  I have the receiver connected to a serial console by an FTDI cable, so that I can track the RSSI and maxRSSI as they change.  I have the transmitter battery powered (no serial console needed) to make it easy to carry and move around.
« Last Edit: January 20, 2016, 01:32:21 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #20 on: January 20, 2016, 04:24:39 AM »
Below is an example snippet of the output:
Code: [Select]
24271. RSSI=-107, maxRSSI=-79
24272. RSSI=-101, maxRSSI=-79
24273. RSSI=-110, maxRSSI=-79
24274. RSSI=-95, maxRSSI=-79
24275. RSSI=-105, maxRSSI=-79
24276. RSSI=-104, maxRSSI=-79
24277. RSSI=-106, maxRSSI=-79
24278. RSSI=-102, maxRSSI=-79
24279. RSSI=-105, maxRSSI=-79
24280. RSSI=-105, maxRSSI=-79
24281. RSSI=-114, maxRSSI=-79
24282. RSSI=-101, maxRSSI=-79
24283. RSSI=-106, maxRSSI=-79
24284. RSSI=-100, maxRSSI=-79
24285. RSSI=-100, maxRSSI=-79
24286. RSSI=-34, maxRSSI=-34
24287. RSSI=-33, maxRSSI=-33
24288. RSSI=-31, maxRSSI=-31
24289. RSSI=-31, maxRSSI=-31
24290. RSSI=-31, maxRSSI=-31
24291. RSSI=-30, maxRSSI=-30
24292. RSSI=-31, maxRSSI=-30
24293. RSSI=-30, maxRSSI=-30
24294. RSSI=-30, maxRSSI=-30
24295. RSSI=-30, maxRSSI=-30
24296. RSSI=-31, maxRSSI=-30
24297. RSSI=-31, maxRSSI=-30
24298. RSSI=-31, maxRSSI=-30
24299. RSSI=-31, maxRSSI=-30
24300. RSSI=-31, maxRSSI=-30
24301. RSSI=-31, maxRSSI=-30
24302. RSSI=-31, maxRSSI=-30
24303. RSSI=-31, maxRSSI=-30
24304. RSSI=-31, maxRSSI=-30
24305. RSSI=-30, maxRSSI=-30
24306. RSSI=-30, maxRSSI=-30
24307. RSSI=-31, maxRSSI=-30
24308. RSSI=-31, maxRSSI=-30
24309. RSSI=-31, maxRSSI=-30
24310. RSSI=-31, maxRSSI=-30
Time index 24286 marks the instant at which I turned on the transmitter Moteino node.  You can see the RSSI immediately increase from a prior maximum of -79dB to an RSSI of -34dB, and very quickly from there to -30dB.  Also, before the transmitter is turned on, the RSSI numbers are fluctuating over a wider range, as you would expect, and once the transmitter is turned on, the RSSI numbers become much more tightly clustered, again as you would perhaps expect.
« Last Edit: January 20, 2016, 01:31:05 PM by WhiteHare »

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #21 on: January 20, 2016, 01:38:14 PM »
Good work.

It appears though that you are actually resetting the receiver by putting into standby and then rx mode in the main loop. What you're not doing though is polling for RSSI interrupt before reading the register. You noticed that increasing the modulus of the printfs didn't have the desired effect of speeding up the measurements, I think that you were resetting the receiver before the RSSI measurments were completed, when you print out that adds a delay and allows the measurement to complete. and put its value in the register so it appears to only update at the rate at which you're printing.

You need the handshake of waiting for RSSI interrupt before reading the RSSI register I think.
Mark.
« Last Edit: January 20, 2016, 01:55:00 PM by perky »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #22 on: January 20, 2016, 02:40:40 PM »
Thanks for your feedback.

You noticed that increasing the modulus of the printfs didn't have the desired effect of speeding up the measurements, I think that you were resetting the receiver before the RSSI measurments were completed, when you print out that adds a delay and allows the measurement to complete. and put its value in the register so it appears to only update at the rate at which you're printing.

Just to clear the air on that: it doesn't happen in Version 2.  There was a bug in version 1 where it was accidently reading RSSI twice per loop instead of once per loop, and for whatever reason that was leading to the perceptible delays I reported earlier.

In this particular instance, what reason is there for thinking that the handshaking is strictly needed?  As long as the reported RSSI values are rapidly updating (as they appear to be), and not stuck reading and re-reading an old stale value, I'm not certain  it will make much, if any, difference whether or not the code waits for a handshake.  Granted, it may depend on how updating the RFM69's RSSI was implemented (e.g. is the update an atomic action which prevents you from reading an answer that's still a work-in-progress?).  Do we even know?  If we don't know, then I agree that waiting for a handshake does, on its face, seem like  it might be a more conservative way of doing it, provided you prevent the RFM69 from initiating another RSSI measurement until you can read the latest RSSI value and then explicitly trigger a new measurement.  Otherwise, the same concern exists.  Plus, the extra overhead for such rigidly controlled handshaking might/probably (?) cause a slower RSSI sample rate, and so there's that as a possible cost to doing it.  i.e. For that reason, the argument can be made that if handshaking is not proven to be needed, it's probably better to avoid handshaking.

Anyhow, food for thought.  Unfortunately, given the unknowns, it's not obvious (at least to me) how to resolve the issue without access to high cost reference equipment.  Lacking that, I suppose one could implement it both ways and then try to somehow judge if one seems better than the other while in actual use.

« Last Edit: January 20, 2016, 04:39:38 PM by WhiteHare »

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #23 on: January 20, 2016, 06:37:58 PM »
OK, let's postulate a potential mode of operation:

1) You put the receiver into RX mode from standby. This triggers an RSSI measurement as the threshold is set below the noise floor. The radio takes 2 bit periods to finish that sample, which is far slower than an SPI register read.
2) You read the RSSI register. RSSI sampling is still ongoing, so the register has not yet been updated.
3) You exit RX mode by putting the radio into standby mode. This clears the logic and stops an on-going RSSI measurement before it has updated the register.
4) loop back to 1.

This potentially means the RSSI register never updates. Now you insert a print out of the RSSI measurement inbetween steps 2 and 3. This introduces a relatively long delay, and since the radio is still in RX mode the RSSI measurement completes and updates the register. The result is every time you print it out you appear to be seeing updated RSSI measurements, it gives the impression it's fast if you print out every time.

How do you know this isn't really happening? One way to tell is instead of printing out the values you stored them in a large array, and at the end printed it all out. If the above is happening then those values wouldn't change, or possibly might change but far slower than you might expect.

Repeat the experiment with polling for RSSI interrupt between steps 1 and 2 and look at the output from the array.
Mark.

Edit: Actually putting the radio into standby mode immediately after reading the RSSI register may have a similar result. If the above is happening then this might terminate the RSSI sample before the register updates and you'll print out unchanging values. Polling for RSSI interrupt before reading the RSSI register might yield changing values, this is a simpler experiment to do with your existing code.
« Last Edit: January 20, 2016, 06:54:45 PM by perky »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #24 on: January 21, 2016, 11:59:36 AM »
Thanks, Perky.  I'm in the middle of doing a deeper dive through the datasheet, and I think your postulation is probably right: the most detailed discussion about sampling the RSSI centers around Figures 18, 19, and 20, and so far it appears the mere act of entering Rx mode is the only thing in the existing code which ultimately triggers fresh RSSI measurements. 

I'd wager there might be some time savings by putting the RFM69 into Rx-WAIT mode by manually setting RestartRx (rather than changing to standby and then back to Rx-mode) to trigger a new RSSI measurement.  If so, maybe that would yield an even faster RSSI update rate.

Anyhow, given your postulation and the above, it stands to reason that the time interval provided by the printing might well be longer than what's needed.  OK, I'm convinced.   :)

So, to make this work with the existing hardware without adding a jumper, it appears I'll need to use Diox mapping 11 (to map RSSI to D00 while in Rx-mode) and attach a new interrupt handler to read the RSSI value and enable RestartRx. 

« Last Edit: January 21, 2016, 01:13:15 PM by WhiteHare »

emjay

  • Full Member
  • ***
  • Posts: 119
  • Country: nl
Re: Real time RSSI measurement broken RFM69CW?
« Reply #25 on: January 21, 2016, 01:12:41 PM »
Isn't polling the Rssi flag in RegIrqFlags1 (0x27) a little easier?

Curious that this bit flag has Mode rwc , one of only two occurrences in the entire document with no key.  Ok, the r and w are obvious, but cc=clear? Why distinguish this from setting to zero via w ?



WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #26 on: January 21, 2016, 01:25:46 PM »
Curious that this bit flag has Mode rwc , one of only two occurrences in the entire document with no key.  Ok, the r and w are obvious, but cc=clear? Why distinguish this from setting to zero via w ?

Maybe the "c" means it's only writable if the RFM69 is in Continuous mode?  At least, I'm tempted to infer that from the comment attached to SyncAddressMatch.  Perhaps the original notation was Wc (as in W subscript c), but the formatting flattened it out and squashed the meaning.

Admittedly, it would mean their notation is a bit inconsistent (i.e. why r/rwc and not just rwc?), but it would seem to fit for RSSI.  In continuous mode maybe (?) you need to clear it yourself in order to prepare for recognizing when a new RSSI is available to read, whereas in packet mode you only get one RSSI value upon entering Rx-mode, and then it's cleared for you automatically when you leave Rx-mode in order to prepare to receive the next RSSI.
« Last Edit: January 21, 2016, 02:14:20 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #27 on: January 21, 2016, 02:23:50 PM »
Isn't polling the Rssi flag in RegIrqFlags1 (0x27) a little easier?

Thanks for pointing that out.   :)  It looks as though once that value goes high it will remain high until the RFM69 exits Rx-mode, whereas I wasn't sure whether the DIOx RSSI pin would remain affirmed or was merely toggled.
« Last Edit: January 21, 2016, 02:28:12 PM by WhiteHare »

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #28 on: January 21, 2016, 03:10:42 PM »
@emjay: I think rwc means that it can only be cleared by writing a 1 to it and cannot be set, rw would imply you can set or clear it but that's generally not done for interrupt status bits. There's a problem if you make them rw for interrupt status bits, you should only clear those bits that you have actually seen high and actioned. If an interrupt should happen in between the reading of the register and the clearing operation you could clear that interrupt before it's even been seen, so they use a 'mask' approach where only the bits written with a 1 get cleared, all other status bits written with a 0 do not get affected in any way.

@WhiteHare: In my experiments I used restart rather than exit RX and re-enter again and is in the pseudo-code, it is probably quicker due to other things happening like PLL re-locking when exiting and re-entering RX mode.

Given you're having to read the RSSI register via SPI and also restarting via SPI, and SPI is fairly quick, it's convenient to read the RSSI interrupt via SPI as emjay says. I agree you could save one SPI register read in your loop by mapping it to DIO0 though (do the mapping once outside the loop of course!).

I think it's safe to assume the DIO pins map to the internal signals which are also readable via SPI, so if they get cleared internally it'll change on the DIO pin its mapped to.
Mark.
« Last Edit: January 21, 2016, 03:25:15 PM by perky »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #29 on: January 22, 2016, 12:31:00 AM »
I implemented a simple version of what was discussed.  RSSIvalue isn't read until after the RSSI flag goes HIGH.  However, I think what will surprise you guys is that after doing so the RSSI value afterward (but before the next Rx cycle is started) doesn't settle onto a single value but rather continues to jump around.

Here's the Version 3.0 code:
Code: [Select]
//Version 3.0

// Sample RFM69 receiver/gateway sketch, with ACK and optional encryption
// Passes through any wireless received messages to the serial port & responds to ACKs
// It also looks for an onboard FLASH chip, if present
// Library and code by Felix Rusu - felix@lowpowerlab.com
// Get the RFM69 and SPIFlash library at: https://github.com/LowPowerLab/

#include <RFM69.h>    //get it here: https://www.github.com/lowpowerlab/rfm69
#include <SPI.h>
#include <SPIFlash.h> //get it here: https://www.github.com/lowpowerlab/spiflash
#include <RFM69registers.h>

#define NODEID        1    //unique for each node on same network
#define NETWORKID     100  //the same on all nodes that talk to each other
//Match frequency to the hardware version of the radio on your Moteino (uncomment one):
//#define FREQUENCY     RF69_433MHZ
//#define FREQUENCY     RF69_868MHZ
#define FREQUENCY     RF69_915MHZ
#define ENCRYPTKEY    "sampleEncryptKey" //exactly the same 16 characters/bytes on all nodes!
#define IS_RFM69HW    //uncomment only for RFM69HW! Leave out if you have RFM69W!
#define SERIAL_BAUD   250000

#ifdef __AVR_ATmega1284P__
  #define LED           15 // Moteino MEGAs have LEDs on D15
  #define FLASH_SS      23 // and FLASH SS on D23
#else
  #define LED           9 // Moteinos have LEDs on D9
  #define FLASH_SS      8 // and FLASH SS on D8
#endif

RFM69 radio;
SPIFlash flash(FLASH_SS, 0xEF30); //EF30 for 4mbit  Windbond chip (W25X40CL)
bool promiscuousMode = false; //set to 'true' to sniff all packets on the same network

void setup() {
  Serial.begin(SERIAL_BAUD);
  delay(10);
  radio.initialize(FREQUENCY,NODEID,NETWORKID);
#ifdef IS_RFM69HW
  radio.setHighPower(); //only for RFM69HW!
#endif
  radio.encrypt(ENCRYPTKEY);
  radio.promiscuous(promiscuousMode);
   
  radio.writeReg(REG_BITRATEMSB, RF_BITRATEMSB_300000);  //set MSB bitrate to 300Kbps
  radio.writeReg(REG_BITRATELSB, RF_BITRATELSB_300000);  //set LSB bitrate to 300Kbps
  Serial.println(F("Bitrate set to 300Kbps."));
 
  char buff[50];
  sprintf(buff, "\nListening at %d Mhz...", FREQUENCY==RF69_433MHZ ? 433 : FREQUENCY==RF69_868MHZ ? 868 : 915);
  Serial.println(buff);
  if (flash.initialize())
  {
    Serial.print("SPI Flash Init OK. Unique MAC = [");
    flash.readUniqueId();
    for (byte i=0;i<8;i++)
    {
      Serial.print(flash.UNIQUEID[i], HEX);
      if (i!=8) Serial.print(':');
    }
    Serial.println(']');
   
    //alternative way to read it:
    //byte* MAC = flash.readUniqueId();
    //for (byte i=0;i<8;i++)
    //{
    //  Serial.print(MAC[i], HEX);
    //  Serial.print(' ');
    //}
   
  }
  else
    Serial.println("SPI Flash Init FAIL! (is chip present?)");

  radio.writeReg(REG_OPMODE, (radio.readReg(REG_OPMODE) & 0xE3) | RF_OPMODE_STANDBY);  //set standby-mode
  radio.writeReg(REG_RSSITHRESH, 0xFF);  //set RSSI threshhold as low as possible
  radio.writeReg(REG_OPMODE, (radio.readReg(REG_OPMODE) & 0xE3) | RF_OPMODE_RECEIVER);  //set Rx-mode   
}
long loopCount=0;
int theRSSI;
int maxRSSI= (-125);
uint8_t regIrqFlags1;

void loop() {
  loopCount++;
 
  while (!(radio.readReg(REG_IRQFLAGS1) & RF_IRQFLAGS1_RSSI)) { //busy-wait until RSSI flag goes HIGH
  }

  for (int i=0;i<10; i++) {
    regIrqFlags1 = radio.readReg(REG_IRQFLAGS1);
    theRSSI = -(radio.readReg(REG_RSSIVALUE))/2;

    if ((theRSSI > maxRSSI)) {
      maxRSSI = theRSSI;
    }
 
    Serial.print(loopCount);Serial.print(F("."));Serial.print(i);
    Serial.print(F(": regIrqFlags1="));Serial.print((regIrqFlags1),BIN);
    Serial.print(F(", RSSI=")); Serial.println(theRSSI);
  }

  radio.writeReg(REG_OPMODE, (radio.readReg(REG_OPMODE) & 0xE3) | RF_OPMODE_STANDBY);  //set standby-mode
  radio.writeReg(REG_OPMODE, (radio.readReg(REG_OPMODE) & 0xE3) | RF_OPMODE_RECEIVER);  //set Rx-mode
}

and here is some sample output:
Code: [Select]
302.0: regIrqFlags1=10011000, RSSI=-79
302.1: regIrqFlags1=11011000, RSSI=-99
302.2: regIrqFlags1=11011000, RSSI=-103
302.3: regIrqFlags1=11011000, RSSI=-98
302.4: regIrqFlags1=11011000, RSSI=-99
302.5: regIrqFlags1=11011000, RSSI=-103
302.6: regIrqFlags1=11011000, RSSI=-101
302.7: regIrqFlags1=11011000, RSSI=-104
302.8: regIrqFlags1=11011000, RSSI=-96
302.9: regIrqFlags1=11011000, RSSI=-104
303.0: regIrqFlags1=10011000, RSSI=-76
303.1: regIrqFlags1=11011000, RSSI=-98
303.2: regIrqFlags1=11011000, RSSI=-127
303.3: regIrqFlags1=11011000, RSSI=-105
303.4: regIrqFlags1=11011000, RSSI=-94
303.5: regIrqFlags1=11011000, RSSI=-96
303.6: regIrqFlags1=11011000, RSSI=-97
303.7: regIrqFlags1=11011000, RSSI=-101
303.8: regIrqFlags1=11011000, RSSI=-100
303.9: regIrqFlags1=11011000, RSSI=-106
304.0: regIrqFlags1=10011000, RSSI=-78
304.1: regIrqFlags1=11011000, RSSI=-95
304.2: regIrqFlags1=11011000, RSSI=-101
304.3: regIrqFlags1=11011000, RSSI=-99
304.4: regIrqFlags1=11011000, RSSI=-99
304.5: regIrqFlags1=11011000, RSSI=-98
304.6: regIrqFlags1=11011000, RSSI=-107
304.7: regIrqFlags1=11011000, RSSI=-98
304.8: regIrqFlags1=11011000, RSSI=-104
304.9: regIrqFlags1=11011000, RSSI=-101
305.0: regIrqFlags1=10011000, RSSI=-81
305.1: regIrqFlags1=11011000, RSSI=-96
305.2: regIrqFlags1=11011000, RSSI=-103
305.3: regIrqFlags1=11011000, RSSI=-99
305.4: regIrqFlags1=11011000, RSSI=-99
305.5: regIrqFlags1=11011000, RSSI=-103
305.6: regIrqFlags1=11011000, RSSI=-99
305.7: regIrqFlags1=11011000, RSSI=-102
305.8: regIrqFlags1=11011000, RSSI=-105
305.9: regIrqFlags1=11011000, RSSI=-98

Is that what you expected?

emjay

  • Full Member
  • ***
  • Posts: 119
  • Country: nl
Re: Real time RSSI measurement broken RFM69CW?
« Reply #30 on: January 22, 2016, 03:06:31 AM »
@WhiteHare,

Interesting indeed. Could you do a run with the ANT pin shorted to GND (ideally with ~50Ω SMD if you have one handy).

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #31 on: January 22, 2016, 07:43:44 AM »
I don't have a 50Ω SMD, but I probably have the equivalent ohms in regular resistors.  Shall I use that?

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #32 on: January 22, 2016, 09:39:21 AM »
The other salient finding is that there's generally roughly  a 15-20dB difference (though sometimes more and sometimes less) between the first reading, when RSSI flag is high and RxReady flag is still LOW, and subsequent readings when both are HIGH.  Almost invariably, that first measurement shows a higher dB (i.e. a less negative number) than the subsequent measurements taken in the same Rx cycle.

FWIW, the results are 100% repeatable.  I've tried it now with the same results on two different computers and with two different USB cables (one of which has a ferrite core on it).

I've also tried it on two different RFM69HW Moteino's (authentic official versions, assembled and soldered at LowPowerLabs, and purchased directly from LowPowerLabs), and the results are the same for both of them.
« Last Edit: January 22, 2016, 11:20:27 AM by WhiteHare »

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #33 on: January 22, 2016, 10:50:01 AM »
You're right, I didn't expect that result!

I think we're closing in on what's happening. I have just repeated your experiment with my own code, and have got exactly the same result. What I noticed though is that the RSSI value will continue to change after the RSSI interrupt without exiting RX mode, but will freeze as soon as a sync address match happens. In theory this could happen with noise, the probability is small and the payload ready is then extremely unlikely to fire due to the CRC mismatch, but if a sync address match ever does happen randomly the receiver will need to be restarted otherwise RSSI values get stuck. This would involve detecting a sync address match in the loop and restarting.

I've just implemented the above fix (i.e. only issue a restart when a sync address match happens, don't exit from RX mode at all in the loop) and it appears to work.

(BTW the way you enter RX and standby modes is not complete, once you've written to the OPMODE register you're supposed to poll the IRQFLAGS register and wait for the MODEREADY to go high to indicate that mode has been selected)
Mark.

emjay

  • Full Member
  • ***
  • Posts: 119
  • Country: nl
Re: Real time RSSI measurement broken RFM69CW?
« Reply #34 on: January 22, 2016, 12:41:46 PM »
@WhiteHare,

A tiny 47Ω discrete would be ok - the issue is avoiding creating much of a loop antenna. Then this (or if you have to, just a solder blob short) should give the noise floor of the Rx section. It's still noise of course, but the substantial spikes you are seeing can't happen, so if similar spikes are present it suggests strongly that the RSSI value strobed out is an artifact of the method.


WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #35 on: January 22, 2016, 12:49:18 PM »
If I switch to the default baudrate provided by Felix's code on both the node and the gateway, and after I power-up the node, then I get the results I would expect, except that reported RSSI seems to lag even after the PayloadReady bit in IrqFlags2 is first reported to have gone HIGH.  On the other hand, once the RSSI value catches up, it stays at that number on subsequent reads within the same Rx-cycle.

Here is an excerpt of the output which illustrates:

Code: [Select]
2177.0: regIrqFlags1=10011000, RSSI=-81, regIrqFlags2=0
2177.1: regIrqFlags1=11011000, RSSI=-100, regIrqFlags2=0
2177.2: regIrqFlags1=11011000, RSSI=-99, regIrqFlags2=0
2177.3: regIrqFlags1=11011000, RSSI=-98, regIrqFlags2=1000110
2177.4: regIrqFlags1=11011001, RSSI=-43, regIrqFlags2=1000110
2177.5: regIrqFlags1=11011001, RSSI=-43, regIrqFlags2=1000110
2177.6: regIrqFlags1=11011001, RSSI=-43, regIrqFlags2=1000110
2177.7: regIrqFlags1=11011001, RSSI=-43, regIrqFlags2=1000110
2177.8: regIrqFlags1=11011001, RSSI=-43, regIrqFlags2=1000110
2177.9: regIrqFlags1=11011001, RSSI=-43, regIrqFlags2=1000110
2178.0: regIrqFlags1=10011000, RSSI=-83, regIrqFlags2=0
2178.1: regIrqFlags1=11011000, RSSI=-99, regIrqFlags2=0
2178.2: regIrqFlags1=11011000, RSSI=-104, regIrqFlags2=0
2178.3: regIrqFlags1=11011000, RSSI=-102, regIrqFlags2=0
2178.4: regIrqFlags1=11011000, RSSI=-100, regIrqFlags2=0
2178.5: regIrqFlags1=11011000, RSSI=-99, regIrqFlags2=0
2178.6: regIrqFlags1=11011000, RSSI=-98, regIrqFlags2=0
2178.7: regIrqFlags1=11011000, RSSI=-92, regIrqFlags2=0
2178.8: regIrqFlags1=11011000, RSSI=-100, regIrqFlags2=0
2178.9: regIrqFlags1=11011000, RSSI=-108, regIrqFlags2=0
2179.0: regIrqFlags1=10011000, RSSI=-81, regIrqFlags2=0
2179.1: regIrqFlags1=11011000, RSSI=-101, regIrqFlags2=0
2179.2: regIrqFlags1=11011000, RSSI=-100, regIrqFlags2=0
2179.3: regIrqFlags1=11011000, RSSI=-99, regIrqFlags2=0
2179.4: regIrqFlags1=11011000, RSSI=-126, regIrqFlags2=0
2179.5: regIrqFlags1=11011000, RSSI=-103, regIrqFlags2=0
2179.6: regIrqFlags1=11011000, RSSI=-96, regIrqFlags2=0
2179.7: regIrqFlags1=11011000, RSSI=-99, regIrqFlags2=0
2179.8: regIrqFlags1=11011000, RSSI=-100, regIrqFlags2=0
2179.9: regIrqFlags1=11011000, RSSI=-100, regIrqFlags2=0
2180.0: regIrqFlags1=10011000, RSSI=-79, regIrqFlags2=0
2180.1: regIrqFlags1=11011000, RSSI=-101, regIrqFlags2=0
2180.2: regIrqFlags1=11011000, RSSI=-99, regIrqFlags2=1000110
2180.3: regIrqFlags1=11011001, RSSI=-44, regIrqFlags2=1000110
2180.4: regIrqFlags1=11011001, RSSI=-44, regIrqFlags2=1000110
2180.5: regIrqFlags1=11011001, RSSI=-44, regIrqFlags2=1000110
2180.6: regIrqFlags1=11011001, RSSI=-44, regIrqFlags2=1000110
2180.7: regIrqFlags1=11011001, RSSI=-44, regIrqFlags2=1000110
2180.8: regIrqFlags1=11011001, RSSI=-44, regIrqFlags2=1000110
2180.9: regIrqFlags1=11011001, RSSI=-44, regIrqFlags2=1000110
2181.0: regIrqFlags1=10011000, RSSI=-81, regIrqFlags2=0
2181.1: regIrqFlags1=11011000, RSSI=-101, regIrqFlags2=0
2181.2: regIrqFlags1=11011000, RSSI=-103, regIrqFlags2=0
2181.3: regIrqFlags1=11011000, RSSI=-103, regIrqFlags2=0
2181.4: regIrqFlags1=11011000, RSSI=-100, regIrqFlags2=0
2181.5: regIrqFlags1=11011000, RSSI=-106, regIrqFlags2=0
2181.6: regIrqFlags1=11011000, RSSI=-103, regIrqFlags2=0
2181.7: regIrqFlags1=11011000, RSSI=-102, regIrqFlags2=0
2181.8: regIrqFlags1=11011000, RSSI=-99, regIrqFlags2=0
2181.9: regIrqFlags1=11011000, RSSI=-97, regIrqFlags2=1000110
2182.0: regIrqFlags1=10011000, RSSI=-80, regIrqFlags2=0

@emjay I'll make an attempt on shorting the antenna and post the results.
« Last Edit: January 22, 2016, 12:55:26 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #36 on: January 22, 2016, 01:41:37 PM »
Oops.  It turns out the "lag" was actually just an artificat of the order in which I was reading the irqFlags.  I corrected it so that irqFlags2 is now read first, and now it matches what you would expect (though maybe there's some lag in the FIFO flags getting cleared, but that's not really consequential):

Reading the registers in this corrected order:
Code: [Select]
    regIrqFlags2 = radio.readReg(REG_IRQFLAGS2);
    regIrqFlags1 = radio.readReg(REG_IRQFLAGS1);
    theRSSI = -(radio.readReg(REG_RSSIVALUE))/2;

yields results like this:
Code: [Select]
441.0: regIrqFlags1=11011000, RSSI=-87, regIrqFlags2=0
441.1: regIrqFlags1=11011000, RSSI=-101, regIrqFlags2=0
441.2: regIrqFlags1=11011000, RSSI=-106, regIrqFlags2=0
441.3: regIrqFlags1=11011001, RSSI=-32, regIrqFlags2=1100110
441.4: regIrqFlags1=11011001, RSSI=-32, regIrqFlags2=1100110
441.5: regIrqFlags1=11011001, RSSI=-32, regIrqFlags2=1100110
441.6: regIrqFlags1=11011001, RSSI=-32, regIrqFlags2=1100110
441.7: regIrqFlags1=11011001, RSSI=-32, regIrqFlags2=1100110
441.8: regIrqFlags1=11011001, RSSI=-32, regIrqFlags2=1100110
441.9: regIrqFlags1=11011001, RSSI=-32, regIrqFlags2=1100110
442.0: regIrqFlags1=11011000, RSSI=-83, regIrqFlags2=1100000
442.1: regIrqFlags1=11011000, RSSI=-100, regIrqFlags2=0
442.2: regIrqFlags1=11011000, RSSI=-101, regIrqFlags2=0
442.3: regIrqFlags1=11011000, RSSI=-98, regIrqFlags2=0
442.4: regIrqFlags1=11011000, RSSI=-96, regIrqFlags2=0
442.5: regIrqFlags1=11011000, RSSI=-102, regIrqFlags2=0
442.6: regIrqFlags1=11011000, RSSI=-101, regIrqFlags2=0
442.7: regIrqFlags1=11011000, RSSI=-102, regIrqFlags2=0
442.8: regIrqFlags1=11011000, RSSI=-96, regIrqFlags2=0
442.9: regIrqFlags1=11011000, RSSI=-104, regIrqFlags2=0
443.0: regIrqFlags1=11011000, RSSI=-52, regIrqFlags2=0
443.1: regIrqFlags1=11011001, RSSI=-32, regIrqFlags2=1100110
443.2: regIrqFlags1=11011001, RSSI=-32, regIrqFlags2=1100110
443.3: regIrqFlags1=11011001, RSSI=-32, regIrqFlags2=1100110
443.4: regIrqFlags1=11011001, RSSI=-32, regIrqFlags2=1100110
443.5: regIrqFlags1=11011001, RSSI=-32, regIrqFlags2=1100110
443.6: regIrqFlags1=11011001, RSSI=-32, regIrqFlags2=1100110
443.7: regIrqFlags1=11011001, RSSI=-32, regIrqFlags2=1100110
443.8: regIrqFlags1=11011001, RSSI=-32, regIrqFlags2=1100110
443.9: regIrqFlags1=11011001, RSSI=-32, regIrqFlags2=1100110
444.0: regIrqFlags1=11011000, RSSI=-90, regIrqFlags2=1100000
444.1: regIrqFlags1=11011000, RSSI=-102, regIrqFlags2=0
444.2: regIrqFlags1=11011000, RSSI=-102, regIrqFlags2=0
444.3: regIrqFlags1=11011000, RSSI=-104, regIrqFlags2=0
444.4: regIrqFlags1=11011000, RSSI=-98, regIrqFlags2=0
444.5: regIrqFlags1=11011000, RSSI=-106, regIrqFlags2=0
444.6: regIrqFlags1=11011000, RSSI=-101, regIrqFlags2=0
444.7: regIrqFlags1=11011000, RSSI=-101, regIrqFlags2=0
444.8: regIrqFlags1=11011000, RSSI=-105, regIrqFlags2=0
444.9: regIrqFlags1=11011001, RSSI=-32, regIrqFlags2=1100110
445.0: regIrqFlags1=11011000, RSSI=-86, regIrqFlags2=1100000

Anyhow, the main point is that the early evidence seems to indicate that the RSSI value doesn't  latch unless payloadReady is HIGH.
« Last Edit: January 22, 2016, 01:52:26 PM by WhiteHare »

emjay

  • Full Member
  • ***
  • Posts: 119
  • Country: nl
Re: Real time RSSI measurement broken RFM69CW?
« Reply #37 on: January 22, 2016, 01:46:21 PM »
@WhiteHare - good work!   Determined prising at the shell will open this oyster eventually...

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #38 on: January 22, 2016, 02:20:18 PM »
You're right, I didn't expect that result!

I think we're closing in on what's happening. I have just repeated your experiment with my own code, and have got exactly the same result. What I noticed though is that the RSSI value will continue to change after the RSSI interrupt without exiting RX mode, but will freeze as soon as a sync address match happens. In theory this could happen with noise, the probability is small and the payload ready is then extremely unlikely to fire due to the CRC mismatch, but if a sync address match ever does happen randomly the receiver will need to be restarted otherwise RSSI values get stuck. This would involve detecting a sync address match in the loop and restarting.

I've just implemented the above fix (i.e. only issue a restart when a sync address match happens, don't exit from RX mode at all in the loop) and it appears to work.

(BTW the way you enter RX and standby modes is not complete, once you've written to the OPMODE register you're supposed to poll the IRQFLAGS register and wait for the MODEREADY to go high to indicate that mode has been selected)
Mark.

Regarding the syncAddressMatch, I think it's probably that way intentionally.  i.e. it's a feature, not a bug.  In my case (see most recent posting of results above), syncAddressMatch happens to go HIGH around the same time that PayloadReady goes HIGH.  Unfortunately, I don't have any cases (yet) where syncAddressMatch goes HIGH but not PayloadReady, so I'm not sure yet which one is essential for latching the RSSI value (or maybe it's neither but instead one of the other flags that goes HIGH around the same time).

[Edit: I looked a bit further and found an example that distinguishes between the two (see below):

Code: [Select]
460.0: regIrqFlags1=11011000, RSSI=-87, regIrqFlags2=0
460.1: regIrqFlags1=11011000, RSSI=-105, regIrqFlags2=0
460.2: regIrqFlags1=11011000, RSSI=-93, regIrqFlags2=0
460.3: regIrqFlags1=11011000, RSSI=-101, regIrqFlags2=0
460.4: regIrqFlags1=11011000, RSSI=-106, regIrqFlags2=0
460.5: regIrqFlags1=11011000, RSSI=-98, regIrqFlags2=0
460.6: regIrqFlags1=11011001, RSSI=-26, regIrqFlags2=1100000
460.7: regIrqFlags1=11011001, RSSI=-30, regIrqFlags2=1100110
460.8: regIrqFlags1=11011001, RSSI=-30, regIrqFlags2=1100110
460.9: regIrqFlags1=11011001, RSSI=-30, regIrqFlags2=1100110
461.0: regIrqFlags1=11011000, RSSI=-86, regIrqFlags2=1100000

So, it would appear it is not syncAddressMatch that does the latching.  Instead, it would appear that it's either PayloadReady or CrcOK that has to go HIGH in order for the RSSI value to latch.  Now I just need to find a similar case that will distinguish between those two....]
« Last Edit: January 22, 2016, 02:52:16 PM by WhiteHare »

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #39 on: January 22, 2016, 05:08:16 PM »
I've just tried putting the receiver into unlimited packet length mode and sampling the RSSI and the two flag registers into arrays within the 10 cycle loop. I kept the FIFO empty by reading when not empty it so as not to trigger a FIFO overflow condition, and this generates a sync address match but with no payload ready.

I can confirm your hypothesis, it appears sync address match does not freeze the RSSI measurements, it must be payloadReady or crcOk. The RSSI measurements continually updated even though syncAddressMatch stayed active until it was reset. However, a lot of the time they didn't seem to be the correct RSSI values! Some of the values were correct (and changed by relatively small amounts around that value within the loop), others were widely off.

Mark.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #40 on: January 22, 2016, 11:13:07 PM »
I unsoldered Felix's wire antenna and then soldered on a 47 ohm resistor to short antenna to ground (see attached photo).  After doing so, here are the results from using the latest version of the sketch:

Code: [Select]
2.0: regIrqFlags1=11011000, RSSI=-86, regIrqFlags2=0
2.1: regIrqFlags1=11011000, RSSI=-106, regIrqFlags2=0
2.2: regIrqFlags1=11011000, RSSI=-104, regIrqFlags2=0
2.3: regIrqFlags1=11011000, RSSI=-104, regIrqFlags2=0
2.4: regIrqFlags1=11011000, RSSI=-105, regIrqFlags2=0
2.5: regIrqFlags1=11011000, RSSI=-105, regIrqFlags2=0
2.6: regIrqFlags1=11011000, RSSI=-105, regIrqFlags2=0
2.7: regIrqFlags1=11011000, RSSI=-108, regIrqFlags2=0
2.8: regIrqFlags1=11011000, RSSI=-107, regIrqFlags2=0
2.9: regIrqFlags1=11011000, RSSI=-104, regIrqFlags2=0
3.0: regIrqFlags1=11011000, RSSI=-89, regIrqFlags2=0
3.1: regIrqFlags1=11011000, RSSI=-101, regIrqFlags2=0
3.2: regIrqFlags1=11011000, RSSI=-107, regIrqFlags2=0
3.3: regIrqFlags1=11011000, RSSI=-107, regIrqFlags2=0
3.4: regIrqFlags1=11011000, RSSI=-104, regIrqFlags2=0
3.5: regIrqFlags1=11011000, RSSI=-105, regIrqFlags2=0
3.6: regIrqFlags1=11011000, RSSI=-104, regIrqFlags2=0
3.7: regIrqFlags1=11011000, RSSI=-102, regIrqFlags2=0
3.8: regIrqFlags1=11011000, RSSI=-110, regIrqFlags2=0
3.9: regIrqFlags1=11011000, RSSI=-99, regIrqFlags2=0
4.0: regIrqFlags1=11011000, RSSI=-86, regIrqFlags2=0
4.1: regIrqFlags1=11011000, RSSI=-106, regIrqFlags2=0
4.2: regIrqFlags1=11011000, RSSI=-107, regIrqFlags2=0
4.3: regIrqFlags1=11011000, RSSI=-109, regIrqFlags2=0
4.4: regIrqFlags1=11011000, RSSI=-101, regIrqFlags2=0
4.5: regIrqFlags1=11011000, RSSI=-107, regIrqFlags2=0
4.6: regIrqFlags1=11011000, RSSI=-105, regIrqFlags2=0
4.7: regIrqFlags1=11011000, RSSI=-106, regIrqFlags2=0
4.8: regIrqFlags1=11011001, RSSI=-104, regIrqFlags2=1000000
4.9: regIrqFlags1=11011000, RSSI=-112, regIrqFlags2=0
5.0: regIrqFlags1=11011000, RSSI=-88, regIrqFlags2=0
5.1: regIrqFlags1=11011000, RSSI=-107, regIrqFlags2=0
5.2: regIrqFlags1=11011000, RSSI=-113, regIrqFlags2=0
5.3: regIrqFlags1=11011000, RSSI=-104, regIrqFlags2=0
5.4: regIrqFlags1=11011000, RSSI=-105, regIrqFlags2=0
5.5: regIrqFlags1=11011000, RSSI=-102, regIrqFlags2=0
5.6: regIrqFlags1=11011000, RSSI=-106, regIrqFlags2=0
5.7: regIrqFlags1=11011000, RSSI=-103, regIrqFlags2=0
5.8: regIrqFlags1=11011000, RSSI=-102, regIrqFlags2=0
5.9: regIrqFlags1=11011000, RSSI=-106, regIrqFlags2=0
6.0: regIrqFlags1=11011000, RSSI=-88, regIrqFlags2=0
6.1: regIrqFlags1=11011000, RSSI=-104, regIrqFlags2=0
6.2: regIrqFlags1=11011000, RSSI=-103, regIrqFlags2=0
6.3: regIrqFlags1=11011000, RSSI=-115, regIrqFlags2=0
6.4: regIrqFlags1=11011000, RSSI=-106, regIrqFlags2=0
6.5: regIrqFlags1=11011000, RSSI=-106, regIrqFlags2=0
6.6: regIrqFlags1=11011000, RSSI=-107, regIrqFlags2=0
6.7: regIrqFlags1=11011000, RSSI=-108, regIrqFlags2=0
6.8: regIrqFlags1=11011000, RSSI=-101, regIrqFlags2=0
6.9: regIrqFlags1=11011000, RSSI=-106, regIrqFlags2=0
7.0: regIrqFlags1=11011000, RSSI=-94, regIrqFlags2=0
7.1: regIrqFlags1=11011000, RSSI=-101, regIrqFlags2=0
7.2: regIrqFlags1=11011000, RSSI=-105, regIrqFlags2=0
7.3: regIrqFlags1=11011000, RSSI=-102, regIrqFlags2=0
7.4: regIrqFlags1=11011000, RSSI=-103, regIrqFlags2=0
7.5: regIrqFlags1=11011000, RSSI=-106, regIrqFlags2=0
7.6: regIrqFlags1=11011000, RSSI=-105, regIrqFlags2=0
7.7: regIrqFlags1=11011000, RSSI=-105, regIrqFlags2=0
7.8: regIrqFlags1=11011000, RSSI=-107, regIrqFlags2=0
7.9: regIrqFlags1=11011000, RSSI=-101, regIrqFlags2=0
8.0: regIrqFlags1=11011000, RSSI=-86, regIrqFlags2=0
8.1: regIrqFlags1=11011000, RSSI=-103, regIrqFlags2=0
8.2: regIrqFlags1=11011000, RSSI=-114, regIrqFlags2=0
8.3: regIrqFlags1=11011000, RSSI=-99, regIrqFlags2=0
8.4: regIrqFlags1=11011000, RSSI=-104, regIrqFlags2=0
8.5: regIrqFlags1=11011000, RSSI=-98, regIrqFlags2=0
8.6: regIrqFlags1=11011000, RSSI=-106, regIrqFlags2=0
8.7: regIrqFlags1=11011000, RSSI=-103, regIrqFlags2=0
8.8: regIrqFlags1=11011000, RSSI=-105, regIrqFlags2=0
8.9: regIrqFlags1=11011000, RSSI=-101, regIrqFlags2=0

What do you think it all means?

Here's the sketch:
Code: [Select]
//Version 3.1

// Sample RFM69 receiver/gateway sketch, with ACK and optional encryption
// Passes through any wireless received messages to the serial port & responds to ACKs
// It also looks for an onboard FLASH chip, if present
// Library and code by Felix Rusu - felix@lowpowerlab.com
// Get the RFM69 and SPIFlash library at: https://github.com/LowPowerLab/

#include <RFM69.h>    //get it here: https://www.github.com/lowpowerlab/rfm69
#include <SPI.h>
#include <SPIFlash.h> //get it here: https://www.github.com/lowpowerlab/spiflash
#include <RFM69registers.h>

#define NODEID        1    //unique for each node on same network
#define NETWORKID     100  //the same on all nodes that talk to each other
//Match frequency to the hardware version of the radio on your Moteino (uncomment one):
//#define FREQUENCY     RF69_433MHZ
//#define FREQUENCY     RF69_868MHZ
#define FREQUENCY     RF69_915MHZ
#define ENCRYPTKEY    "sampleEncryptKey" //exactly the same 16 characters/bytes on all nodes!
#define IS_RFM69HW    //uncomment only for RFM69HW! Leave out if you have RFM69W!
#define SERIAL_BAUD   250000

#ifdef __AVR_ATmega1284P__
  #define LED           15 // Moteino MEGAs have LEDs on D15
  #define FLASH_SS      23 // and FLASH SS on D23
#else
  #define LED           9 // Moteinos have LEDs on D9
  #define FLASH_SS      8 // and FLASH SS on D8
#endif

RFM69 radio;
SPIFlash flash(FLASH_SS, 0xEF30); //EF30 for 4mbit  Windbond chip (W25X40CL)
bool promiscuousMode = false; //set to 'true' to sniff all packets on the same network

void setup() {
  Serial.begin(SERIAL_BAUD);
  delay(10);
  radio.initialize(FREQUENCY,NODEID,NETWORKID);
#ifdef IS_RFM69HW
  radio.setHighPower(); //only for RFM69HW!
#endif
  radio.encrypt(ENCRYPTKEY);
  radio.promiscuous(promiscuousMode);
   
  //radio.writeReg(REG_BITRATEMSB, RF_BITRATEMSB_300000);  //set MSB bitrate to 300Kbps
  //radio.writeReg(REG_BITRATELSB, RF_BITRATELSB_300000);  //set LSB bitrate to 300Kbps
  //Serial.println(F("Bitrate set to 300Kbps."));
  Serial.println(F("Default bitrate."));
 
  char buff[50];
  sprintf(buff, "\nListening at %d Mhz...", FREQUENCY==RF69_433MHZ ? 433 : FREQUENCY==RF69_868MHZ ? 868 : 915);
  Serial.println(buff);
  if (flash.initialize())
  {
    Serial.print("SPI Flash Init OK. Unique MAC = [");
    flash.readUniqueId();
    for (byte i=0;i<8;i++)
    {
      Serial.print(flash.UNIQUEID[i], HEX);
      if (i!=8) Serial.print(':');
    }
    Serial.println(']');
   
    //alternative way to read it:
    //byte* MAC = flash.readUniqueId();
    //for (byte i=0;i<8;i++)
    //{
    //  Serial.print(MAC[i], HEX);
    //  Serial.print(' ');
    //}
   
  }
  else
    Serial.println("SPI Flash Init FAIL! (is chip present?)");

  radio.writeReg(REG_OPMODE, (radio.readReg(REG_OPMODE) & 0xE3) | RF_OPMODE_STANDBY);  //set standby-mode
  radio.writeReg(REG_RSSITHRESH, 0xFF);  //set RSSI threshhold as low as possible
  radio.writeReg(REG_OPMODE, (radio.readReg(REG_OPMODE) & 0xE3) | RF_OPMODE_RECEIVER);  //set Rx-mode   
}
long loopCount=0;
int theRSSI;
int maxRSSI= (-125);
uint8_t regIrqFlags1, regIrqFlags2;

void loop() {
  loopCount++;
 
  while (!(radio.readReg(REG_IRQFLAGS1) & RF_IRQFLAGS1_RSSI)) { //busy-wait until RSSI flag goes HIGH
  }

  for (int i=0;i<10; i++) {
    regIrqFlags2 = radio.readReg(REG_IRQFLAGS2);
    regIrqFlags1 = radio.readReg(REG_IRQFLAGS1);
    theRSSI = -(radio.readReg(REG_RSSIVALUE))/2;

    if ((theRSSI > maxRSSI)) {
      maxRSSI = theRSSI;
    }
 
    Serial.print(loopCount);Serial.print(F("."));Serial.print(i);
    Serial.print(F(": regIrqFlags1="));Serial.print((regIrqFlags1),BIN);
    Serial.print(F(", RSSI=")); Serial.print(theRSSI);
    Serial.print(F(", regIrqFlags2="));Serial.println((regIrqFlags2),BIN);
  }

  radio.writeReg(REG_OPMODE, (radio.readReg(REG_OPMODE) & 0xE3) | RF_OPMODE_STANDBY);  //set standby-mode
  radio.writeReg(REG_OPMODE, (radio.readReg(REG_OPMODE) & 0xE3) | RF_OPMODE_RECEIVER);  //set Rx-mode
}



I can see how using an SMD resistor would have been ideal.  Unfortunately, I don't have any on-hand.  If anyone else does, feel free to repeat the test using that together with the same sketch, and then post.
« Last Edit: January 23, 2016, 12:28:35 AM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #41 on: January 23, 2016, 12:22:47 AM »
I've just tried putting the receiver into unlimited packet length mode and sampling the RSSI and the two flag registers into arrays within the 10 cycle loop. I kept the FIFO empty by reading when not empty it so as not to trigger a FIFO overflow condition, and this generates a sync address match but with no payload ready.

I can confirm your hypothesis, it appears sync address match does not freeze the RSSI measurements, it must be payloadReady or crcOk. The RSSI measurements continually updated even though syncAddressMatch stayed active until it was reset. However, a lot of the time they didn't seem to be the correct RSSI values! Some of the values were correct (and changed by relatively small amounts around that value within the loop), others were widely off.

Mark.

I disabled CRC and re-ran the earlier test using a regular Moteino (not the one with the shorted antenna above).  The results show that PayloadReady is the essential flag for latching the RSSI value:

Code: [Select]
796.0: regIrqFlags1=11011000, RSSI=-82, regIrqFlags2=0
796.1: regIrqFlags1=11011000, RSSI=-105, regIrqFlags2=0
796.2: regIrqFlags1=11011000, RSSI=-106, regIrqFlags2=0
796.3: regIrqFlags1=11011000, RSSI=-104, regIrqFlags2=0
796.4: regIrqFlags1=11011001, RSSI=-39, regIrqFlags2=1000100
796.5: regIrqFlags1=11011001, RSSI=-39, regIrqFlags2=1000100
796.6: regIrqFlags1=11011001, RSSI=-39, regIrqFlags2=1000100
796.7: regIrqFlags1=11011001, RSSI=-39, regIrqFlags2=1000100
796.8: regIrqFlags1=11011001, RSSI=-39, regIrqFlags2=1000100
796.9: regIrqFlags1=11011001, RSSI=-39, regIrqFlags2=1000100
797.0: regIrqFlags1=11011000, RSSI=-83, regIrqFlags2=1000000

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #42 on: January 23, 2016, 03:54:10 AM »
For the moment, I removed flagsIrq2 from consideration and ran the latest version (version 4.0) of the sketch on the Moteino whose antenna is nominally shorted.  BTW, it now uses RxRestart in the main loop.

I also turned on the transmitter and found that even with the antenna "shorted," it was still receiving some packets:

Code: [Select]
1.0: regIrqFlags1=10011000, RSSI=-82
1.1: regIrqFlags1=11011000, RSSI=-101
1.2: regIrqFlags1=11011000, RSSI=-102
1.3: regIrqFlags1=11011000, RSSI=-109
1.4: regIrqFlags1=11011000, RSSI=-104
1.5: regIrqFlags1=11011000, RSSI=-107
1.6: regIrqFlags1=11011000, RSSI=-111
1.7: regIrqFlags1=11011000, RSSI=-101
1.8: regIrqFlags1=11011000, RSSI=-109
1.9: regIrqFlags1=11011000, RSSI=-105
2.0: regIrqFlags1=10011000, RSSI=-81
2.1: regIrqFlags1=11011000, RSSI=-103
2.2: regIrqFlags1=11011001, RSSI=-56
2.3: regIrqFlags1=11011001, RSSI=-58
2.4: regIrqFlags1=11011001, RSSI=-58
2.5: regIrqFlags1=11011001, RSSI=-58
2.6: regIrqFlags1=11011001, RSSI=-58
2.7: regIrqFlags1=11011001, RSSI=-58
2.8: regIrqFlags1=11011001, RSSI=-58
2.9: regIrqFlags1=11011001, RSSI=-58
3.0: regIrqFlags1=10011000, RSSI=-77
3.1: regIrqFlags1=11011000, RSSI=-102
3.2: regIrqFlags1=11011000, RSSI=-104
3.3: regIrqFlags1=11011000, RSSI=-107
3.4: regIrqFlags1=11011000, RSSI=-107
3.5: regIrqFlags1=11011000, RSSI=-107
3.6: regIrqFlags1=11011000, RSSI=-100
3.7: regIrqFlags1=11011000, RSSI=-110
3.8: regIrqFlags1=11011000, RSSI=-102
3.9: regIrqFlags1=11011000, RSSI=-105
4.0: regIrqFlags1=10011000, RSSI=-81
4.1: regIrqFlags1=11011000, RSSI=-105
4.2: regIrqFlags1=11011000, RSSI=-99
4.3: regIrqFlags1=11011000, RSSI=-103
4.4: regIrqFlags1=11011000, RSSI=-104
4.5: regIrqFlags1=11011000, RSSI=-100
4.6: regIrqFlags1=11011000, RSSI=-102
4.7: regIrqFlags1=11011000, RSSI=-107
4.8: regIrqFlags1=11011000, RSSI=-101
4.9: regIrqFlags1=11011001, RSSI=-58
5.0: regIrqFlags1=10011000, RSSI=-76
5.1: regIrqFlags1=11011000, RSSI=-105
5.2: regIrqFlags1=11011000, RSSI=-101
5.3: regIrqFlags1=11011000, RSSI=-104
5.4: regIrqFlags1=11011000, RSSI=-103
5.5: regIrqFlags1=11011000, RSSI=-109
5.6: regIrqFlags1=11011000, RSSI=-105
5.7: regIrqFlags1=11011000, RSSI=-104
5.8: regIrqFlags1=11011000, RSSI=-108
5.9: regIrqFlags1=11011000, RSSI=-102
6.0: regIrqFlags1=10011000, RSSI=-81
6.1: regIrqFlags1=11011000, RSSI=-107
6.2: regIrqFlags1=11011000, RSSI=-107
6.3: regIrqFlags1=11011000, RSSI=-106
6.4: regIrqFlags1=11011000, RSSI=-108
6.5: regIrqFlags1=11011000, RSSI=-102
6.6: regIrqFlags1=11011000, RSSI=-103
6.7: regIrqFlags1=11011000, RSSI=-103
6.8: regIrqFlags1=11011000, RSSI=-103
6.9: regIrqFlags1=11011000, RSSI=-110
7.0: regIrqFlags1=10011000, RSSI=-82
7.1: regIrqFlags1=11011000, RSSI=-106
7.2: regIrqFlags1=11011000, RSSI=-105
7.3: regIrqFlags1=11011000, RSSI=-102
7.4: regIrqFlags1=11011000, RSSI=-101
7.5: regIrqFlags1=11011001, RSSI=-54
7.6: regIrqFlags1=11011001, RSSI=-57
7.7: regIrqFlags1=11011001, RSSI=-57
7.8: regIrqFlags1=11011001, RSSI=-57
7.9: regIrqFlags1=11011001, RSSI=-57
8.0: regIrqFlags1=10011000, RSSI=-77
8.1: regIrqFlags1=11011000, RSSI=-103
8.2: regIrqFlags1=11011000, RSSI=-105
8.3: regIrqFlags1=11011000, RSSI=-107
8.4: regIrqFlags1=11011000, RSSI=-109
8.5: regIrqFlags1=11011000, RSSI=-109
8.6: regIrqFlags1=11011000, RSSI=-103
8.7: regIrqFlags1=11011000, RSSI=-101
8.8: regIrqFlags1=11011000, RSSI=-107
8.9: regIrqFlags1=11011000, RSSI=-111
9.0: regIrqFlags1=10011000, RSSI=-82
9.1: regIrqFlags1=11011000, RSSI=-107
9.2: regIrqFlags1=11011000, RSSI=-105
9.3: regIrqFlags1=11011000, RSSI=-106
9.4: regIrqFlags1=11011000, RSSI=-102
9.5: regIrqFlags1=11011000, RSSI=-105
9.6: regIrqFlags1=11011000, RSSI=-107
9.7: regIrqFlags1=11011000, RSSI=-103
9.8: regIrqFlags1=11011000, RSSI=-105
9.9: regIrqFlags1=11011000, RSSI=-107
10.0: regIrqFlags1=10011000, RSSI=-82

Here's the current sketch which produced the above results:
Code: [Select]
//Version 4.0

// Sample RFM69 receiver/gateway sketch, with ACK and optional encryption
// Passes through any wireless received messages to the serial port & responds to ACKs
// It also looks for an onboard FLASH chip, if present
// Library and code by Felix Rusu - felix@lowpowerlab.com
// Get the RFM69 and SPIFlash library at: https://github.com/LowPowerLab/

#include <RFM69.h>    //get it here: https://www.github.com/lowpowerlab/rfm69
#include <SPI.h>
#include <SPIFlash.h> //get it here: https://www.github.com/lowpowerlab/spiflash
#include <RFM69registers.h>

#define NODEID        1    //unique for each node on same network
#define NETWORKID     100  //the same on all nodes that talk to each other
//Match frequency to the hardware version of the radio on your Moteino (uncomment one):
//#define FREQUENCY     RF69_433MHZ
//#define FREQUENCY     RF69_868MHZ
#define FREQUENCY     RF69_915MHZ
#define ENCRYPTKEY    "sampleEncryptKey" //exactly the same 16 characters/bytes on all nodes!
#define IS_RFM69HW    //uncomment only for RFM69HW! Leave out if you have RFM69W!
#define SERIAL_BAUD   250000

#ifdef __AVR_ATmega1284P__
  #define LED           15 // Moteino MEGAs have LEDs on D15
  #define FLASH_SS      23 // and FLASH SS on D23
#else
  #define LED           9 // Moteinos have LEDs on D9
  #define FLASH_SS      8 // and FLASH SS on D8
#endif

RFM69 radio;
SPIFlash flash(FLASH_SS, 0xEF30); //EF30 for 4mbit  Windbond chip (W25X40CL)
bool promiscuousMode = false; //set to 'true' to sniff all packets on the same network
uint8_t oldRegPacketConfig1,newRegPacketConfig1;
uint8_t oldPacketConfig2, newPacketConfig2;

void setup() {
  Serial.begin(SERIAL_BAUD);
  delay(10);
  radio.initialize(FREQUENCY,NODEID,NETWORKID);
#ifdef IS_RFM69HW
  radio.setHighPower(); //only for RFM69HW!
#endif
  radio.encrypt(ENCRYPTKEY);
  radio.promiscuous(promiscuousMode);
   
  //radio.writeReg(REG_BITRATEMSB, RF_BITRATEMSB_300000);  //set MSB bitrate to 300Kbps
  //radio.writeReg(REG_BITRATELSB, RF_BITRATELSB_300000);  //set LSB bitrate to 300Kbps
  //Serial.println(F("Bitrate set to 300Kbps."));
  Serial.println(F("Default bitrate."));
 
  char buff[50];
  sprintf(buff, "\nListening at %d Mhz...", FREQUENCY==RF69_433MHZ ? 433 : FREQUENCY==RF69_868MHZ ? 868 : 915);
  Serial.println(buff);
  if (flash.initialize())
  {
    Serial.print("SPI Flash Init OK. Unique MAC = [");
    flash.readUniqueId();
    for (byte i=0;i<8;i++)
    {
      Serial.print(flash.UNIQUEID[i], HEX);
      if (i!=8) Serial.print(':');
    }
    Serial.println(']');
   
    //alternative way to read it:
    //byte* MAC = flash.readUniqueId();
    //for (byte i=0;i<8;i++)
    //{
    //  Serial.print(MAC[i], HEX);
    //  Serial.print(' ');
    //}
   
  }
  else
    Serial.println("SPI Flash Init FAIL! (is chip present?)");

  //oldRegPacketConfig1 = radio.readReg(REG_PACKETCONFIG1);
  //newRegPacketConfig1 = oldRegPacketConfig1 & ((RF_PACKET1_CRC_ON)^0xFF); //clear CRC_ON bit
   
  radio.writeReg(REG_OPMODE, (radio.readReg(REG_OPMODE) & 0xE3) | RF_OPMODE_STANDBY);  //set standby-mode
  radio.writeReg(REG_RSSITHRESH, 0xFF);  //set RSSI threshhold as low as possible
  //radio.writeReg(REG_PACKETCONFIG1,newRegPacketConfig1);  //disable CRC checking
  radio.writeReg(REG_OPMODE, (radio.readReg(REG_OPMODE) & 0xE3) | RF_OPMODE_RECEIVER);  //set Rx-mode   
}


long loopCount=0;
int theRSSI;
int maxRSSI= (-125);
uint8_t regIrqFlags1, regIrqFlags2;

void loop() {
  loopCount++;
 
  while (!(radio.readReg(REG_IRQFLAGS1) & RF_IRQFLAGS1_RSSI)) { //busy-wait until RSSI flag goes HIGH
  }

  for (int i=0;i<10; i++) {
    //regIrqFlags2 = radio.readReg(REG_IRQFLAGS2);
    regIrqFlags1 = radio.readReg(REG_IRQFLAGS1);
    theRSSI = -(radio.readReg(REG_RSSIVALUE))/2;

    //if ((theRSSI > maxRSSI)) {
      //maxRSSI = theRSSI;
    //}
 
    Serial.print(loopCount);Serial.print(F("."));Serial.print(i);
    Serial.print(F(": regIrqFlags1="));Serial.print((regIrqFlags1),BIN);
    Serial.print(F(", RSSI=")); Serial.println(theRSSI);
    //Serial.print(F(", regIrqFlags2="));Serial.println((regIrqFlags2),BIN);
  }

  oldPacketConfig2 = radio.readReg(REG_PACKETCONFIG2);
  newPacketConfig2 = (oldPacketConfig2 | RF_PACKET2_RXRESTART); //set RxRestart bit
  radio.writeReg(REG_PACKETCONFIG2,newPacketConfig2); //transition to Rx-WAIT mode
}

So, here are my conclusions:
1.  Obviously, some external RF is getting into the system, even with a "shorted" antenna.  So, that may explain, either fully or in-part, the varying RSSI.
2.  If you want to measure RSSI, wait until the RxReady flag goes HIGH.  The RSSI measured after the RSSI flag goes HIGH but before the RxReady flag goes HIGH seems less accurate. 

What are your conclusions?

emjay

  • Full Member
  • ***
  • Posts: 119
  • Country: nl
Re: Real time RSSI measurement broken RFM69CW?
« Reply #43 on: January 23, 2016, 07:44:49 AM »
@WhiteHare,

Those ~20dB RSSI jumps are difficult to explain - I was hoping that with the 'null' input, they would disappear. Then it is reasonable to conclude that at least the jumps are external RF (and hence unavoidable), not an artifact of RSSI measurement/strobing.

To track this down further would need something like enclosing the entire UIT in a metal box - harder than it seems since any wires into the box need extensive decoupling.  The result does echo one of your previous threads though - UHF penetrates amazingly well, even into the traces/components between the ANT pin and the RFIO pin on the chip.  If you want to chase the limits of range (LoRa or classic), it is worth paying a lot of attention to screening/isolation of the super sensitive Rx front end.  If not, the desired signal is just wallowing in excessive noise.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #44 on: January 23, 2016, 09:36:04 PM »
To further "null" the input, I suppose one could run the Moteino on batteries and then put the entire thing inside a closed metal box, have it record some measurements into either an array or the memory chip for later playback, and then play the measurements back after opening up the box again. 

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 »

emjay

  • Full Member
  • ***
  • Posts: 119
  • Country: nl
Re: Real time RSSI measurement broken RFM69CW?
« Reply #60 on: January 27, 2016, 04:58:43 PM »
@WhiteHare,

Quote
I'm not sure how to check whether or not they (AGC, AFC) are disabled, because I don't see an explicit enabled/disabled bit for either one.

I think you have found already - for completeness AGC is controlled by RegLna (0x18), AFC by RegAfcFei (0x1E)

Quote
Not to overcomplicate the discussion, but does DC cancellation figure into this at all?

In brief, no.  ZeroIF is when the local oscillator is approximately the same frequency as the nominal transmit carrier frequency, the one that is waggled +/- fdev for the frequency shift keying.  The local oscillator Flocal is fed with the (amplified) input signal Fc into the mixer section to produce the classic sum and difference results, k x Flocal +/- Fc. 
Now some local oscillator leaks into the area around the ANT pin, so that appears to be input signal (self reception) at exacty Flocal. Plug that into the mixer equation and the result is something at zero frequency.  Huh?  What does that mean?
Well that is just a D.C. term.  There is no useful information content and it is not healthy for the linearity of the following stages, so a sharp roll-off filter is introduced just after the mixer to cut off DC - Fcutoff.
The default setting for Fcutoff can be trusted.




perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #61 on: January 27, 2016, 05:47:15 PM »
Which is also why I think adding a small offset for AFC when using low beta signals where most of the enegy is concentrated around the carrier frequency gives better sensitivity, there is an effective  'notch' in the filter due to the DC cancelling roll-off.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #62 on: January 28, 2016, 02:06:24 AM »
This post confirms a finding that Perky posted just recently:

If I setup to do an RxRestart after every measurement of RSSI, and if I record the time interval between RSSI measurements, an interesting pattern emerges:

Code: [Select]
---------------------------------------------------------------------
Radio Configuration:
====================
Receiver-Mode(RX)
Packet Mode, FSK modulation scheme
[ActualBitrate] 4799.760bps = nominal bitrate of 4800bps
[RxBw] 10416Hz
  [RxBwExp] B101 (Bits 0-2 of regRXBW) = 5
  [theRxBwMant] B10 (Bits 3-4 of regRXBW) -> [RxBwMant] 24
---------------------------------------------------------------------
0.0. RSSI=-116
1.0. RSSI=-116, elapsed=108uSec
2.0. RSSI=-116, elapsed=104uSec
3.0. RSSI=-116, elapsed=116uSec
4.0. RSSI=-116, elapsed=104uSec
5.0. RSSI=-116, elapsed=108uSec
6.0. RSSI=-115, elapsed=1752uSec
7.0. RSSI=-115, elapsed=112uSec
8.0. RSSI=-115, elapsed=108uSec
9.0. RSSI=-115, elapsed=108uSec
10.0. RSSI=-115, elapsed=104uSec
11.0. RSSI=-115, elapsed=108uSec
12.0. RSSI=-116, elapsed=1760uSec
13.0. RSSI=-116, elapsed=104uSec
14.0. RSSI=-116, elapsed=108uSec
15.0. RSSI=-116, elapsed=108uSec
16.0. RSSI=-116, elapsed=104uSec
17.0. RSSI=-116, elapsed=108uSec
18.0. RSSI=-115, elapsed=1760uSec
19.0. RSSI=-115, elapsed=104uSec
20.0. RSSI=-115, elapsed=108uSec
21.0. RSSI=-115, elapsed=104uSec
22.0. RSSI=-115, elapsed=108uSec
23.0. RSSI=-115, elapsed=108uSec
24.0. RSSI=-113, elapsed=1756uSec
25.0. RSSI=-113, elapsed=108uSec
26.0. RSSI=-113, elapsed=108uSec
27.0. RSSI=-113, elapsed=112uSec
28.0. RSSI=-113, elapsed=108uSec
29.0. RSSI=-113, elapsed=104uSec
30.0. RSSI=-116, elapsed=1752uSec
31.0. RSSI=-116, elapsed=116uSec
32.0. RSSI=-116, elapsed=104uSec
33.0. RSSI=-116, elapsed=108uSec
34.0. RSSI=-116, elapsed=108uSec
35.0. RSSI=-116, elapsed=104uSec
36.0. RSSI=-119, elapsed=1736uSec
37.0. RSSI=-119, elapsed=104uSec
38.0. RSSI=-119, elapsed=108uSec
39.0. RSSI=-119, elapsed=104uSec
40.0. RSSI=-119, elapsed=108uSec
41.0. RSSI=-119, elapsed=108uSec
42.0. RSSI=-115, elapsed=1756uSec
43.0. RSSI=-115, elapsed=108uSec
44.0. RSSI=-115, elapsed=108uSec
45.0. RSSI=-115, elapsed=104uSec
46.0. RSSI=-115, elapsed=108uSec
47.0. RSSI=-115, elapsed=108uSec
48.0. RSSI=-114, elapsed=1756uSec
49.0. RSSI=-114, elapsed=108uSec
50.0. RSSI=-114, elapsed=108uSec
51.0. RSSI=-114, elapsed=104uSec
52.0. RSSI=-114, elapsed=112uSec
53.0. RSSI=-114, elapsed=108uSec
54.0. RSSI=-119, elapsed=1752uSec
55.0. RSSI=-119, elapsed=108uSec
56.0. RSSI=-119, elapsed=112uSec
57.0. RSSI=-119, elapsed=108uSec
58.0. RSSI=-119, elapsed=104uSec
59.0. RSSI=-119, elapsed=108uSec
60.0. RSSI=-117, elapsed=1732uSec
61.0. RSSI=-117, elapsed=108uSec
62.0. RSSI=-117, elapsed=108uSec
63.0. RSSI=-117, elapsed=104uSec
64.0. RSSI=-117, elapsed=108uSec
65.0. RSSI=-117, elapsed=108uSec
66.0. RSSI=-114, elapsed=1756uSec
67.0. RSSI=-114, elapsed=108uSec
68.0. RSSI=-114, elapsed=108uSec
69.0. RSSI=-114, elapsed=104uSec
70.0. RSSI=-114, elapsed=108uSec
71.0. RSSI=-114, elapsed=108uSec
72.0. RSSI=-115, elapsed=1756uSec
73.0. RSSI=-115, elapsed=108uSec
74.0. RSSI=-115, elapsed=108uSec
75.0. RSSI=-115, elapsed=104uSec
76.0. RSSI=-115, elapsed=108uSec
77.0. RSSI=-115, elapsed=112uSec
78.0. RSSI=-116, elapsed=1752uSec
79.0. RSSI=-116, elapsed=108uSec
80.0. RSSI=-116, elapsed=112uSec
81.0. RSSI=-116, elapsed=108uSec
82.0. RSSI=-116, elapsed=104uSec
83.0. RSSI=-116, elapsed=108uSec
84.0. RSSI=-115, elapsed=1760uSec
85.0. RSSI=-115, elapsed=104uSec
86.0. RSSI=-115, elapsed=108uSec
87.0. RSSI=-115, elapsed=108uSec
88.0. RSSI=-115, elapsed=104uSec
89.0. RSSI=-115, elapsed=108uSec
90.0. RSSI=-115, elapsed=1732uSec
91.0. RSSI=-115, elapsed=108uSec
92.0. RSSI=-115, elapsed=108uSec
93.0. RSSI=-115, elapsed=104uSec
94.0. RSSI=-115, elapsed=108uSec
95.0. RSSI=-115, elapsed=104uSec
96.0. RSSI=-116, elapsed=1760uSec
97.0. RSSI=-116, elapsed=108uSec
98.0. RSSI=-116, elapsed=104uSec
99.0. RSSI=-116, elapsed=108uSec
Very often when the RSSI does change, it coincides with a much longer time to take the RSSI measurement (an order of magnitude longer).

That is to say: at lower bitrates such as these, the period between fresh RSSI measurements is noticeably longer.
« Last Edit: January 28, 2016, 02:42:09 AM by WhiteHare »

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #63 on: January 28, 2016, 01:28:09 PM »
This is exactly what I saw, a significant delay introduced some time after the RxRestart was issued. It's strange because it wasn't immediate. I think that the MODEREADY bit also went inactive then active again at some point after issuing the restart as well, but again this wasn't immediate.
Mark.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #64 on: January 29, 2016, 04:45:47 PM »
I unsoldered Felix's wire antenna and then soldered on a 47 ohm resistor to short antenna to ground (see attached photo). ...

I can see how using an SMD resistor would have been ideal.  Unfortunately, I don't have any on-hand.

It seems I can get 47 ohm 1% SMD resistors from China for the cost of a postage stamp and waiting a month, so I'm game.  Which do you suppose would be easier to solder onto the RFM69 to short the antenna: a 1206 or 0805? 

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #65 on: January 29, 2016, 06:06:27 PM »
The ANT input has an impedance anyway (either 200R or 50R however it is programmed), it is effecftively already pulled low at the sx1231h. The only thing left is the small stub on the PCB to the actual pin which could act like a tiny antenna. Tacking the ANT pin to GND would I think be sufficient, terminating with 50R I don't think will make a great deal of difference. You'd normally match the impedances for maximum power transfer, but in this case you explicitly want no power transferred.


WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #66 on: January 29, 2016, 06:21:32 PM »
Excellent point.  No need to wait for 30 days either.   :) 

In summary, I plan to un-install the 47 ohm resistor sometime this weekend and then bridge between ANT and GND using a solder tack.    Afterward, I'll post the resulting RSSI measurements.

Thanks!

emjay

  • Full Member
  • ***
  • Posts: 119
  • Country: nl
Re: Real time RSSI measurement broken RFM69CW?
« Reply #67 on: January 30, 2016, 01:55:00 AM »
@WhiteHare - with your "short" in place, remember not to turn on Tx full blast !

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #68 on: January 30, 2016, 03:10:28 AM »
Yup, no plans to turn on the Tx at all on the shorted unit.

BTW, I completed uninstalling the 47 ohm resistor and adding the solder tack.  My initial impression, though, is that the solder tack seems to perform about the same when running the RSSI sketches.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #69 on: January 30, 2016, 01:10:14 PM »
Using the solder tacked antenna, if I stretch the time between RxRestart's, then the measured RSSI's become seemless at the transitions between just before the RxRestart and just after the RxRestart:

Code: [Select]
Radio Configuration:
====================
Receiver-Mode(RX)
Packet Mode, FSK modulation scheme
[ActualBitrate] 4799.760bps = nominal bitrate of 4800bps
[theDccFreq] B10 (equals Semtech default)
[RxBw] 10416Hz
  [RxBwMant] 24
  [RxBwExp] 5
[theDccFreqAfc] B100 (equals Semtech default)
[RxBwAfc] 50000Hz
  [RxBwMantAfc] 20
  [RxBwExpAfc] 3
[FDev] 5004Hz
[frequency-center] 915000000Hz
[regLNA] B1001
  [LnaZin] B0 -> Input Impedance = 50 ohm (Warning:  Semtech default is 200 ohm).
  [LnaCurrentGain] B1 -> G1
  [LnaGainSelect] B1 -> G1  (Note: Manually selected.  AGC disabled.)
                   ^Warning: does not match Semtech default.
[regAFCFEI] B10000
  [FeiDone] B0 -> FEI is on-going (i.e. not finished).  Matches Semtech default.
  [AfcDone] B1 -> AFC is finished (i.e. not on-going).  Matches Semtech default.
  [AfcAutoclearOn] B0 -> Invalid, because AfcAutoOn is not set.
  [AfcAutoOn] B0 -> AFC is performed each time AfcStart is set (i.e. not each time Rx mode is entered).
                    Matches Semtech default.
---------------------------------------------------------------------
[deleted beginning because of 10,000 character posting limit]
0.246. RSSI=-117
0.247. RSSI=-117
0.248. RSSI=-117
0.249. RSSI=-117
1.0. RSSI=-117
1.1. RSSI=-117
1.2. RSSI=-117
1.3. RSSI=-117
1.4. RSSI=-117
1.5. RSSI=-117
1.6. RSSI=-117
1.7. RSSI=-117
1.8. RSSI=-117
1.9. RSSI=-117
1.10. RSSI=-117
1.11. RSSI=-117
1.12. RSSI=-117
1.13. RSSI=-117
1.14. RSSI=-117
1.15. RSSI=-117
1.16. RSSI=-117
1.17. RSSI=-117
1.18. RSSI=-117
1.19. RSSI=-117
1.20. RSSI=-117
1.21. RSSI=-117
1.22. RSSI=-117
1.23. RSSI=-117
1.24. RSSI=-117
1.25. RSSI=-117
1.26. RSSI=-117
1.27. RSSI=-117
1.28. RSSI=-117
1.29. RSSI=-117
1.30. RSSI=-117
1.31. RSSI=-117
1.32. RSSI=-117
1.33. RSSI=-117
1.34. RSSI=-117
1.35. RSSI=-117
1.36. RSSI=-117
1.37. RSSI=-117
1.38. RSSI=-117
1.39. RSSI=-117
1.40. RSSI=-117
1.41. RSSI=-117
1.42. RSSI=-117
1.43. RSSI=-117
1.44. RSSI=-117
1.45. RSSI=-117
1.46. RSSI=-117
1.47. RSSI=-117
1.48. RSSI=-117
1.49. RSSI=-117
1.50. RSSI=-117
1.51. RSSI=-117
1.52. RSSI=-117
1.53. RSSI=-117
1.54. RSSI=-117
1.55. RSSI=-117
1.56. RSSI=-117
1.57. RSSI=-117
1.58. RSSI=-117
1.59. RSSI=-117
1.60. RSSI=-117
1.61. RSSI=-117
1.62. RSSI=-117
1.63. RSSI=-117
1.64. RSSI=-117
1.65. RSSI=-117
1.66. RSSI=-117
1.67. RSSI=-117
1.68. RSSI=-117
1.69. RSSI=-117
1.70. RSSI=-117
1.71. RSSI=-117
1.72. RSSI=-117
1.73. RSSI=-117
1.74. RSSI=-117
1.75. RSSI=-117
1.76. RSSI=-117
1.77. RSSI=-117
1.78. RSSI=-117
1.79. RSSI=-116
1.80. RSSI=-116
1.81. RSSI=-116
1.82. RSSI=-116
1.83. RSSI=-116
1.84. RSSI=-116
1.85. RSSI=-116
1.86. RSSI=-116
1.87. RSSI=-116
1.88. RSSI=-116
1.89. RSSI=-116
1.90. RSSI=-116
1.91. RSSI=-116
1.92. RSSI=-116
1.93. RSSI=-116
1.94. RSSI=-117
1.95. RSSI=-117
1.96. RSSI=-117
1.97. RSSI=-117
1.98. RSSI=-117
1.99. RSSI=-117
1.100. RSSI=-117
1.101. RSSI=-117
1.102. RSSI=-117
1.103. RSSI=-117
1.104. RSSI=-117
1.105. RSSI=-117
1.106. RSSI=-117
1.107. RSSI=-117
1.108. RSSI=-117
1.109. RSSI=-114
1.110. RSSI=-114
1.111. RSSI=-114
1.112. RSSI=-114
1.113. RSSI=-114
1.114. RSSI=-114
1.115. RSSI=-114
1.116. RSSI=-114
1.117. RSSI=-114
1.118. RSSI=-114
1.119. RSSI=-114
1.120. RSSI=-114
1.121. RSSI=-114
1.122. RSSI=-114
1.123. RSSI=-114
1.124. RSSI=-114
1.125. RSSI=-114
1.126. RSSI=-114
1.127. RSSI=-114
1.128. RSSI=-114
1.129. RSSI=-114
1.130. RSSI=-114
1.131. RSSI=-114
1.132. RSSI=-114
1.133. RSSI=-114
1.134. RSSI=-114
1.135. RSSI=-114
1.136. RSSI=-114
1.137. RSSI=-114
1.138. RSSI=-119
1.139. RSSI=-119
1.140. RSSI=-119
1.141. RSSI=-119
1.142. RSSI=-119
1.143. RSSI=-119
1.144. RSSI=-119
1.145. RSSI=-119
1.146. RSSI=-119
1.147. RSSI=-119
1.148. RSSI=-119
1.149. RSSI=-119
1.150. RSSI=-119
1.151. RSSI=-119
1.152. RSSI=-118
1.153. RSSI=-118
1.154. RSSI=-118
1.155. RSSI=-118
1.156. RSSI=-118
1.157. RSSI=-118
1.158. RSSI=-118
1.159. RSSI=-118
1.160. RSSI=-118
1.161. RSSI=-118
1.162. RSSI=-118
1.163. RSSI=-118
1.164. RSSI=-118
1.165. RSSI=-118
1.166. RSSI=-118
1.167. RSSI=-118
1.168. RSSI=-118
1.169. RSSI=-118
1.170. RSSI=-118
1.171. RSSI=-118
1.172. RSSI=-118
1.173. RSSI=-118
1.174. RSSI=-118
1.175. RSSI=-118
1.176. RSSI=-118
1.177. RSSI=-118
1.178. RSSI=-118
1.179. RSSI=-118
1.180. RSSI=-118
1.181. RSSI=-118
1.182. RSSI=-113
1.183. RSSI=-113
1.184. RSSI=-113
1.185. RSSI=-113
1.186. RSSI=-113
1.187. RSSI=-113
1.188. RSSI=-113
1.189. RSSI=-113
1.190. RSSI=-113
1.191. RSSI=-113
1.192. RSSI=-113
1.193. RSSI=-113
1.194. RSSI=-113
1.195. RSSI=-113
1.196. RSSI=-114
1.197. RSSI=-114
1.198. RSSI=-114
1.199. RSSI=-114
1.200. RSSI=-114
1.201. RSSI=-114
1.202. RSSI=-114
1.203. RSSI=-114
1.204. RSSI=-114
1.205. RSSI=-114
1.206. RSSI=-114
1.207. RSSI=-114
1.208. RSSI=-114
1.209. RSSI=-114
1.210. RSSI=-114
1.211. RSSI=-118
1.212. RSSI=-118
1.213. RSSI=-118
1.214. RSSI=-118
1.215. RSSI=-118
1.216. RSSI=-118
1.217. RSSI=-118
1.218. RSSI=-118
1.219. RSSI=-118
1.220. RSSI=-118
1.221. RSSI=-118
1.222. RSSI=-118
1.223. RSSI=-118
1.224. RSSI=-118
1.225. RSSI=-116
1.226. RSSI=-116
1.227. RSSI=-116
1.228. RSSI=-116
1.229. RSSI=-116
1.230. RSSI=-116
1.231. RSSI=-116
1.232. RSSI=-116
1.233. RSSI=-116
1.234. RSSI=-116
1.235. RSSI=-116
1.236. RSSI=-116
1.237. RSSI=-116
1.238. RSSI=-116
1.239. RSSI=-116
1.240. RSSI=-114
1.241. RSSI=-114
1.242. RSSI=-114
1.243. RSSI=-114
1.244. RSSI=-114
1.245. RSSI=-114
1.246. RSSI=-114
1.247. RSSI=-114
1.248. RSSI=-114
1.249. RSSI=-114
2.0. RSSI=-114
2.1. RSSI=-114
2.2. RSSI=-114

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #70 on: February 06, 2016, 02:49:49 PM »
Which is also why I think adding a small offset for AFC when using low beta signals where most of the enegy is concentrated around the carrier frequency gives better sensitivity, there is an effective  'notch' in the filter due to the DC cancelling roll-off.

Which DCC have you settled on using?

I don't know how thoroughly John K2Ox tested, or whether he had AFC on-off, but John K2Ox reported improved sensitivity with smaller percentage DCC settings.  He also found improvement by using a different DCC setting when senseboost was enabled than when senseboost was disabled:  https://lowpowerlab.com/forum/index.php/topic,222.msg955.html#msg955

On the other hand, I notice Joe Lucid is using DCC=000b (equals 16%):  https://lowpowerlab.com/forum/index.php/topic,982.0.html

So, two smart guys but seemingly opposite conclusions from one another.

Then there's Semtech, which seems to be suggesting DCC of 010b (=4%) for RxBw as the default, but 100b (=1%) as its default for AfcBw.

These numbers are all over the map!

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #71 on: February 06, 2016, 05:38:17 PM »
I use the ones given in the Freescale app note for AFC of 0.5% for both RxBw and RxBwAfc, but I'm now also using a modulation index of around 1 as does this app note..

Let's think about this, remember the DCC cutoff frequency is effectively half the width of the 'notch' in the full receiver filter bandwidth (because the full receiver bandwidth is two 'single side' RxBw bandwidths back to back).

In high index modulation systems the energy of the signal is concentrated around the two modulation frequencies and not at the centre frequency (i.e at Fc+Fdev and Fc-Fdev) so it would make sense that increasing the DCC cutoff would increase sensitivity, because you are widening the notch in the middle which removes some noise but there's not a lot of signal there. The Semtech datasheet says "The cutoff frequency of the DCC can however be increased to slightly improve the sensitivity, under wider modulation conditions". This is therefore consistent.

On the other hand, for low index modulation most of the signal energy is not at the modulation frequencies but instead concentrated around the centre carrier frequency, so widening the notch in that case would have the opposite effect, you'll be removing energy from your signal and decrease sensitivity. Hence the Freescale AFC app note uses a small DCC cut-off of 0.5%.

So I think the answer depends on whether your are using a high or low modulation index. At least that is how I understand it.

Mark.
« Last Edit: February 06, 2016, 05:41:04 PM by perky »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #72 on: February 06, 2016, 07:26:35 PM »
That does shed light on things.  However, for low beta, that app note says:
"Settings to be used:
RX LO offset should be set to between 10% and 15% of Fdev.
RX BW should be greater than the single sideband signal bandwidth + RX LO offset.
DCC should be about 10% of the RX LO Offset"

That would imply DCC of 1.0-1.5%.  So that probably means DCC = 100b, because the nearest settings on either side of that are 0.5% and 2%.

I don't know how that app note arrived at the 0.5% figure (Table 2 of the appt note), unless maybe that's what it should be if AFC is disabled (?).

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #73 on: February 07, 2016, 02:40:58 AM »
DCC cutoff frequency is relative to RxBw, not Fdev. If anything the app not sets it too high:

RxBw = 156.24kHz
LowBetaOffset = 3.416kHz
so 10% of LowBetaOffset = 341.6Hz, which is 0.22% of RxBw.

But then is does say 'about 10%' and also says you should fine tune it by looking at the sensitivity as you do it.


WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #74 on: February 07, 2016, 09:55:01 AM »
DCC cutoff frequency is relative to RxBw, not Fdev.
You're right.  Now it makes sense.  I finally get it.  Thank you! 

...and also says you should fine tune it by looking at the sensitivity as you do it.
I do wish the appt note had elaborated on that.  Just how does one "look at the sensitivity as you do it"?  It reads almost like some kind of screw adjustment.  One idea that I'm toying with is to perhaps average a large number of the RSSI's that we're now getting, say 10,000 or 100,000 or 1,000,000 of them.  Then, since there are only eight possible DCC values, just index through all of them, and for each one print the average RSSI for that setting.  Then perhaps repeat that cycling again a few more times just to ensure that the results are consistent and not thrown off by some intermittent interference source.  Assuming that shows a consistent pattern, then the prefered DCC would be the one with the lowest average RSSI (i.e. experiencing the least noise).  Is that how you're approaching it, or do you see a better way?

I suppose the proper way to do it isn't that but rather to have test equipment that can be wired directly to the receiver antenna so as to reliably send packets at known power levels to the receiver, and then to ratchet down the power to the spec-sheet levels for receive sensitivity.  Then fiddle with the DCC values to find the best seting to receive at.  However, since I don't have the equipment to do it that way (do you?), I'm just trying to figure out what would be the next best thing.
« Last Edit: February 07, 2016, 10:38:42 AM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #75 on: February 12, 2016, 01:35:11 PM »
Here's a tentative plan on how to implement Perky's suggestion for sleeping while the RSSI measurement is taken.  Use the above methods to figure out the period of the RSSI measurement (by noticing how often it updates).  Using that information, then on the next RSSI update, put *everything* to sleep except for the radio.  Then, sometime *after* the *next* RSSI measurement is taken, wake-up the atmega and read the latched RSSI value from the radio.  That value will have been measured while the atmega and everything else was asleep, and thus it is the measurement we want.  Obviously, the timing of the wakeup has to be precise so as to not read an RSSI that was latched after the wakeup has happened.

I'm tempted to rely on an external interrupt to wake the atmega rather than the atmega's internal clock, if only because of the atmega's proximity to the radio.   I'm not sure what to use for that, though.  Any suggestions?

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #76 on: February 12, 2016, 04:46:25 PM »
Could you just map RSSI onto DIO0 and wake it up with that? Something like this:

Map RSSI to DI0
Put into RX mode
Immediately go to sleep
Wake up with RSSI rising edge
Immediately read RSSI register


WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #77 on: February 12, 2016, 05:12:51 PM »
Excellent idea!

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #78 on: February 12, 2016, 09:34:54 PM »
Given that RSSI threshhold is set to 0xFF, it turns out that once RSSI goes HIGH, it simply stays high.  i.e. it can't be used to signal that there's a new RSSI value to read, unless an RX restart has occured, which temporarily sets RSSI back to zero.  It takes about 6.8ms between initiating an RX restart and RSSI going HIGH, so the new plan is to initiate an RX Restart, immediately put the atmega to sleep, and then wait for the RSSI to wakeup the atmega, at which point read the RSSI value.  The only question is whether the RSSI value will have been resampled again between initiating the atmega wake-up and being able to read the RSSI value.  If so, the RSSI value that's read may be polluted.  This is where knowing 1. the period of RSSI resamplings, and 2. how long it takes the atmega to wakeup, and 3. how long it takes the atmega to go into powerdown sleep will help.  So, those three things are next to measure.



« Last Edit: February 13, 2016, 11:47:10 AM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #79 on: February 13, 2016, 11:47:15 AM »
OK, I measured the time between RSSI updates as 1.5ms, so that's a tight constraint.  The update interval is very consistent.  So, the atmega will need to fully wake-up from powerdown and read the RSSI in less time than that.  However, IIRC, at 8mhz the atmega will take longer than that.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #80 on: February 13, 2016, 01:48:45 PM »
Good news!  It turns out that if you do an Rx Restart, then the very first RSSI measurement that results from the Rx Restart will latch for more than 8ms.  After that, and before the next such Rx Restart, the RSSI will update about every 1.5ms. 

I altered the earlier code to record RSSI only when there's a change in RSSI value.  Then, after adding timestamps, the pattern becomes clear:

Code: [Select]
---------------------------------------------------------------------
0.0. RSSI=-120
0.1. RSSI=-123, deltaT=9208uSec
0.2. RSSI=-122, deltaT=1576uSec
0.3. RSSI=-125, deltaT=1528uSec
0.4. RSSI=-121, deltaT=1504uSec
0.5. RSSI=-125, deltaT=1576uSec
---------------------------------------------------------------------
0.0. RSSI=-126
0.1. RSSI=-125, deltaT=8624uSec
0.2. RSSI=-124, deltaT=1520uSec
0.3. RSSI=-123, deltaT=1520uSec
0.4. RSSI=-124, deltaT=1576uSec
0.5. RSSI=-125, deltaT=1512uSec
---------------------------------------------------------------------
0.0. RSSI=-124
0.1. RSSI=-125, deltaT=8672uSec
0.2. RSSI=-124, deltaT=1576uSec
0.3. RSSI=-121, deltaT=1512uSec
0.4. RSSI=-124, deltaT=1520uSec
0.5. RSSI=-125, deltaT=1576uSec
---------------------------------------------------------------------
0.0. RSSI=-127
0.1. RSSI=-123, deltaT=8624uSec
0.2. RSSI=-126, deltaT=1520uSec
0.3. RSSI=-125, deltaT=1560uSec
0.4. RSSI=-124, deltaT=1528uSec
0.5. RSSI=-124, deltaT=1520uSec
---------------------------------------------------------------------


An 8ms window should be wide enough for a Moteino to wake from deep powerdown and read the latched RSSI before it changes.

« Last Edit: February 13, 2016, 02:23:56 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #81 on: February 16, 2016, 12:33:28 AM »
I've run across an unexpected problem, which is that when I map DIO0 to RSSI, it will trigger the interrupt on D2 (interrupt 0 on the atmega328p) almost immediately.  It doesn't matter whether I attached the interrupt at RISING, FALLING, CHANGE, or LOW: the outcome is the same.  Because of this problem, I can't  get the atmega328p into powerdown sleep.  This problem does *not* manifest if I map DIO0 to PayloadReady, as Felix's library does.

What's especially odd is that if I read the RSSI flag (i.e. bit 3 in RegIrqFlags1 (0x27)), it is LOW when I expect it to be, and it goes HIGH when I expect it should.  It does not appear  to be jumping around.

I am mystified as to what is going on.  Has anyone else here run across this issue? 

[Edit: Adding a pulldown resistor does appear to "solve" the problem, but apparently 10K is too low a value, because now RSSI *never* seems to trigger, as opposed to all-the-time without a pulldown resistor.  What would be a good ohm value to use?]
« Last Edit: February 16, 2016, 02:39:09 AM by WhiteHare »

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #82 on: February 16, 2016, 07:02:32 AM »
That's curious, 10k is quite high really and you'd expect a driver to source current to drive it high, sx1231h can sink and source at least 1mA on its digitil outputs according to the spec.

Can you poll the D2 pin instead of using an interrupt to see whether it's the interrupt code that's not working properly?

I can imagine when selecting the RSSI on DIO0 that there could be a positive going glitch as this is done with a binary mux in the radio, binary values can transition through other states while it settles and temporarily mux through a high. You'll most likely see that on a 'scope and it might trigger an edge detection in the interrupt logic. You might consider the following procedure:

disabling interrupts
map RSSI (could cause spurious edge detection)
clear the interrupt flag
re-enable interrupts

Mark.
 

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #83 on: February 16, 2016, 10:09:14 AM »
I've been mapping RSSI to DIO0 only once, and that is in the "setup()" function.

I just now physically severed the pulldown resistor, so now we're back to square one.

After shifting from Rx-Idle into Rx-Read mode,  if I wait for RSSI to go high by running the code
Code: [Select]
while (!(digitalRead(D2))) {}
then RSSI appears to go high after about 32-40 microseconds.  That's the same as what I get if I do attach the interrupt.  That's far too fast, because it takes longer than that just for the PLL to lock.

On the other hand, if I instead wait for RSSI to go high by running the code
Code: [Select]
while (!(radio.readReg(0x27) & 0x08)) { }  //wait for RSSI to go high
then RSSI appears to go high after close to 7000 microseconds, which is also pretty much exactly the same amount of time it takes for RxReady to go HIGH.  I'm assuming this wait time is correct.  Note that I'm first setting the radio to idle mode, waiting for ModeReady, then putting the radio into Rx mode and then recording a timeStamp of when that occurs so as to measure the length of time to RSSI going high.  An RxRestart would be *much* faster, but in this case I don't want faster.  Indeed, I want it as slow as possible to give plenty of time for putting the atmega into deep powerdown sleep mode.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #84 on: February 16, 2016, 11:08:56 AM »
Argh.  Looks as though the connection between DIO0 and D2 came loose.  In the course of repairing it just now, I apparently nuked the radio (maybe an ESD).   :'(

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #85 on: February 16, 2016, 11:13:53 AM »
OK, interesting result. Just thinking, but I had a problem some time back that I didn't really get to the bottom of when going from standby mode to rx mode it would fail to receive the next packet properly - this was pretty odd. In that case an RSSI interrupt was generated but no sync address match. If I put the radio to sleep rather than standby that problem went away. This could be related, I think idle mode is mapped to standby mode in the RadioHead library, could you change it to map to sleep mode instead? There could be an issue here with the way the radio resets when entering rx mode after from standby.
Mark

Edit: Nuking things always happen when you least want it to happen (which is never), hope you fix it soon.
« Last Edit: February 16, 2016, 11:15:24 AM by perky »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #86 on: February 16, 2016, 12:53:48 PM »
Thanks for the encouragement.   :)

So as to continue, I just now hooked up a factory fresh Moteino with the regular RFM69HW and wire antenna using Felix's FTDI connector.  So, this is a little different, because Antenna is not shorted to ground, it has a wire antenna, and its voltage regulator is still intact.  On the plus side, though, is that the hardware hasn't been monkeyed with, and so I don't expect anything will come loose anytime soon.  Also, all of what follows should be easily reproducible by anyone reading this.

Here's the TL;DR summary: with this setup there is a disparity between the results that come from just reading the D2 pin versus attaching an interrupt to the D2 pin.

Using:
Code: [Select]
while (!(digitalRead(D2))) {}  // Wait for RSSI to go HIGH

the RSSI flag doesn't appear to go high until about 6968uSeconds after putting the RFM69HW into Rx Mode:


Code: [Select]
---------------------------------------------------------------------
RSSI=-116, rssiFlagRising=6968uSec
RSSI=-118, rssiFlagRising=6968uSec
RSSI=-117, rssiFlagRising=6968uSec
RSSI=-115, rssiFlagRising=6968uSec
---------------------------------------------------------------------


However, if I attach an interrupt instead to D2 and attempt to get the atmega328p to enter powerdown sleep, what I get instead is:

Code: [Select]
---------------------------------------------------------------------
RSSI=-118, rssiFlagRising=12uSec
RSSI=-118, rssiFlagRising=16uSec
RSSI=-118, rssiFlagRising=16uSec
RSSI=-118, rssiFlagRising=12uSec
---------------------------------------------------------------------
RSSI=-115, rssiFlagRising=12uSec
RSSI=-115, rssiFlagRising=16uSec
RSSI=-115, rssiFlagRising=16uSec
RSSI=-115, rssiFlagRising=16uSec
---------------------------------------------------------------------
RSSI=-116, rssiFlagRising=16uSec
RSSI=-116, rssiFlagRising=16uSec
RSSI=-116, rssiFlagRising=12uSec
RSSI=-116, rssiFlagRising=16uSec
---------------------------------------------------------------------
RSSI=-117, rssiFlagRising=16uSec
RSSI=-117, rssiFlagRising=16uSec
RSSI=-117, rssiFlagRising=12uSec
RSSI=-117, rssiFlagRising=16uSec
---------------------------------------------------------------------

Obviously, that is a dramatic difference.

The code I'm using to attach the interrupt, powerdown, and wake up, is Nick Gammon's "Sketch J" ( http://www.gammon.com.au/power), which I  simply repackaged as "sleepNow()":

Code: [Select]
#include <avr/sleep.h>

void wake ()
{
  // cancel sleep as a precaution
  sleep_disable();
  // precautionary while we do other stuff
  detachInterrupt (0);
 
}  // end of wake


void sleepNow ()
{
  // disable ADC
  ADCSRA = 0; 
 
  set_sleep_mode (SLEEP_MODE_PWR_DOWN); 
  sleep_enable();

  // Do not interrupt before we go to sleep, or the
  // ISR will detach interrupts and we won't wake.
  noInterrupts ();
 
  // will be called when pin D2 goes HIGH 
  attachInterrupt (0, wake, RISING);
  EIFR = bit (INTF0);  // clear flag for interrupt 0
 
  // turn off brown-out enable in software
  // BODS must be set to one and BODSE must be set to zero within four clock cycles
  MCUCR = bit (BODS) | bit (BODSE);
  // The BODS bit is automatically cleared after three clock cycles
  MCUCR = bit (BODS);
 
  // We are guaranteed that the sleep_cpu call will be done
  // as the processor executes the next instruction after
  // interrupts are turned on.
  interrupts ();  // one cycle
  sleep_cpu ();   // one cycle

  } // end of sleepNow()

The only difference between the first and second sets of results is that I replaced:
Code: [Select]
while (!(digitalRead(D2))) {}  // Wait for RSSI to go HIGH

with

Code: [Select]
sleepNow();


If anyone has a better way to handle the interrupt scenario, please post a link and I'll try it instead.  Normally Gammon's code works just fine for me, but just not now when DIO0 is mapped to RSSI.  What's clear is that the atmega328p never even fully gets into deep powerdown sleep, because if it did, it would take about 2.1ms (at 8Mhz) just to wake up.
« Last Edit: February 16, 2016, 01:04:21 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #87 on: February 16, 2016, 01:34:00 PM »
In my experimental setup (before the connection between DIO0 and D2 became loose), I did notice some noise on the D2 pin (see first attachment).

By mapping PllLock onto the D3 pin, and running another o-scope probe to that, I was able to determine that the big spike on D2 exactly coincineded with PllLock  going HIGH (see second attachment).  There, D2 is in yellow, and D3 is in blue.

As a workaround, I tried waiting until after PllLock went high before invoking SleepNow(), but the end result was basically the same, just delayed by the amount it waited for PllLock to go HIGH.  So, something else besides just that PllLock spike is in play, maybe something too brief for my scope to capture but yet still able to trigger an interrupt (assuming that's even possible).

By the way, the experimental setup was being run off a battery and with no voltage regulator.
« Last Edit: February 16, 2016, 02:05:47 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #88 on: February 16, 2016, 01:47:10 PM »
Anyhow, that nasty voltage spike was there on literally every cycle that took the RFM69 from idle-mode into Rx-mode (see attachment).

So, this is just a data dump.  I didn't anticipate this roadblock, and I'm really not sure where to take it from here.  One idea that might work (I haven't tried it) is to map RxReady onto DIO4, wire that to D3, and then (hopefully) attach an interrupt to that for wake-up purposes.  The RFM69HW has a DIO4, which is the only pin that RxReady can be mapped to.  Unfortunately, the RFM69CW from the OP doesn't have a DIO4 on it.  Aside from that, or maybe making another attempt at adding a pulldown resistor, I'm out of ideas.  If there were a way to squelch or prevent the voltage spikes (?) or whatever it is that's prematurely triggering the interrupt, that would of course be worth trying.  However, I'm not sure how to approach doing that, as this is all pretty far afield and more or less where the road ends, at least for me.

Hopefully something in the above rings a bell for someone on how to proceed.

« Last Edit: February 16, 2016, 04:39:03 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #89 on: February 16, 2016, 05:12:13 PM »
I think I found something which may inform what's going on.  If I disconnect DIO0 from D2 but run the code above anyway (the version that is  using the interrupt attachment), the result is:

Code: [Select]
---------------------------------------------------------------------
RSSI=-127, rssiFlagRising=32uSec
RSSI=-127, rssiFlagRising=32uSec
RSSI=-127, rssiFlagRising=24uSec
RSSI=-127, rssiFlagRising=24uSec
---------------------------------------------------------------------
RSSI=-127, rssiFlagRising=32uSec
RSSI=-127, rssiFlagRising=32uSec
RSSI=-127, rssiFlagRising=32uSec
RSSI=-127, rssiFlagRising=32uSec
---------------------------------------------------------------------
RSSI=-127, rssiFlagRising=32uSec
RSSI=-127, rssiFlagRising=24uSec
RSSI=-127, rssiFlagRising=24uSec
RSSI=-127, rssiFlagRising=32uSec
---------------------------------------------------------------------
RSSI=-127, rssiFlagRising=32uSec
RSSI=-127, rssiFlagRising=32uSec
RSSI=-127, rssiFlagRising=32uSec
RSSI=-127, rssiFlagRising=32uSec
---------------------------------------------------------------------

It makes sense that RSSI=-127, because PllLock hasn't yet gone high.  So, the pregnant questions are:
1.  Why wasn't RSSI=-127 when DIO0 was wired to D2?  After all, it triggered at nearly the same time.  My hypothesis is there must have been noise travelling from D2 into DIO0, and then into the radio.
2.  Why does the interrupt trigger at all?  Nothing is coming from DIO0 to trigger D2.  Because there is no pulldown or pullup resistor, D2 is  just a floating pin, so it must be triggering off whatever noise happens to be on D2.  And whatever that noise is, it seems to hit the RISING threshhold fairly consistently at about 24-32uSec after putting the RFM69 into Rx Mode.

So, if I disconnect more wires from the radio one by one, and rerun the code, perhaps I'll narrow it down to the wire or wires which are causing D2 to trigger at the 24-32uSec mark, and that, then, would be a likely suspect for the noise.

[Edit: OK, so I next severed the wire that was connecting DIO3 to D3 (where D3 was using the default 00 mapping to FifoFull.  Wow, the results sure did surprise me:

Code: [Select]
---------------------------------------------------------------------
RSSI=-117, rssiFlagRising=24uSec
RSSI=-119, rssiFlagRising=32uSec
RSSI=-120, rssiFlagRising=32uSec
RSSI=-122, rssiFlagRising=32uSec
---------------------------------------------------------------------
RSSI=-121, rssiFlagRising=32uSec
RSSI=-119, rssiFlagRising=32uSec
RSSI=-116, rssiFlagRising=32uSec
RSSI=-115, rssiFlagRising=32uSec
---------------------------------------------------------------------
RSSI=-116, rssiFlagRising=32uSec
RSSI=-119, rssiFlagRising=32uSec
RSSI=-118, rssiFlagRising=24uSec
RSSI=-119, rssiFlagRising=32uSec
---------------------------------------------------------------------
RSSI=-119, rssiFlagRising=32uSec
RSSI=-118, rssiFlagRising=32uSec
RSSI=-115, rssiFlagRising=32uSec
RSSI=-124, rssiFlagRising=32uSec
---------------------------------------------------------------------
RSSI=-114, rssiFlagRising=24uSec
RSSI=-118, rssiFlagRising=32uSec
RSSI=-117, rssiFlagRising=32uSec
RSSI=-121, rssiFlagRising=24uSec
---------------------------------------------------------------------
RSSI=-118, rssiFlagRising=24uSec
RSSI=-116, rssiFlagRising=24uSec
RSSI=-121, rssiFlagRising=32uSec
RSSI=-120, rssiFlagRising=32uSec
---------------------------------------------------------------------

Now RSSI is showing noise again!   WTF?  How does that make any sense?  FifoFull should have been false, so presumably DIO3 was acting like a ground to D3, which was configured as an input, and therefore high impedance, at least to DC (but maybe not high impedance to high frequency noise?).   Is that a possible explanation?]
« Last Edit: February 16, 2016, 05:56:35 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #90 on: February 17, 2016, 02:41:37 AM »
1.  I tried out 10K pull down resistors again.  No effect.  The previous trial of pull down resistors should be thrown out, because of the break that had occured between DIO0 and D2.
2.  As discussed above, I tried mapping DIO4 to RxReady and wiring to D3, hoping to circumvent the issues surrounding RSSI.  Nope.  Same issues.

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #91 on: February 17, 2016, 05:14:27 AM »
Did you try going into sleep mode rather than standby before rx mode? (idle mode is mapped to standby in the Radiohead libraries. It can be mapped to sleep mode instead). I saw a real difference with this.

Mark.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #92 on: February 17, 2016, 06:09:36 AM »
By sleep mode do you mean listen-mode (i.e. the rfm69 sleeps, but uses its clock to wake itself up at regular intervals)?  The reason I ask is that if it were just sleep mode, I'm not sure how it would ever wake up, as the atmega would be sleeping too.

I experimented a bit more with pulldown resistors.  It turns out 27 ohms still isn't low enough, whereas 22 ohms is already too low.  So, I don't think a pulldown resistor is going to solve it.

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #93 on: February 17, 2016, 07:17:01 AM »
No, I mean when the radio is put into RX mode from either standby or sleep, this is supposed to 'reset' the logic but I saw a difference when going from standby to rx to when going from sleep to rx. This might not be relevant to what you're doing though.

I hope you don't mean 22 ohms, that'll take 150mA at 3.3V! The sx1231h can supply +/-1mA from it's pin (up to close to the rails), the resistance has to be 3k3 or greater.
Mark.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #94 on: February 17, 2016, 06:30:41 PM »
If there were an emoticon for face-palm, I'd be inserting it here. ::) 

It just dawned on me that during full power down the clock is turned off, so there's no way to check elapsed time.  So, it's quite likely the atmega328p actually did go into full powerdown, and it only appeared that it didn't because the clock counter was suspended while it slept.   Of course, with benefit of hindsight, it becomes completely obvious.  Just not obvious when I was in the thick of it.

I'll check it  out, but very likely that's a factor, if not the entire explanation. 

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #95 on: February 17, 2016, 09:57:37 PM »
OK, I checked it out more thoroughly this time by using the scope by adjusting the code to set a pin HIGH when SleepNow() was invoked and LOW after it woke up.

Bottom line:  It *was* getting prematurely woken up by the PllLock pulse (see previous o-scope pictures above).  However, the workaround really does work: just wait until after PllLock goes HIGH, and then sleep in deep powerdown mode.  After doing that, nothing else woke it up prematurely.  The scope shows that after RSSI goes HIGH, the atmega wakes up 2.1ms later and records the RSSI values at that time. 

My initial impression is that it does look as though there may be some reduction in average noise by capturing RSSI while the moteino is asleep, and fortunately it's very easy to do.  So, as a practical matter, if listening to very faint signals, it may be worthwhile to put the atmega into deep powerdown sleep while leaving the RFM69 in Rx mode.  However, it would probably only matter at the margin, for signals that are very near the noise floor.
« Last Edit: February 17, 2016, 11:33:01 PM by WhiteHare »

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Real time RSSI measurement broken RFM69CW?
« Reply #96 on: February 18, 2016, 09:13:37 AM »
Quote
It *was* getting prematurely woken up by the PllLock

This is normal - the 11 DIO mapping gives you RSSI during RX and Plllock during FS which is an intermediate state before the sequencer switches to RX.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #97 on: February 18, 2016, 11:14:10 AM »
Quote
It *was* getting prematurely woken up by the PllLock

This is normal - the 11 DIO mapping gives you RSSI during RX and Plllock during FS which is an intermediate state before the sequencer switches to RX.

Interesting.  That sharpens my understanding of how it all really works.

Hence, it should be more efficient to shift into FS mode rather than Standby mode before shifting back into Rx mode.  Then one wouldn't need to spin wheels waiting for PllLock to go high before sleeping.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #98 on: February 19, 2016, 04:52:15 AM »
For a moteino with the antenna solder tacked to ground, with voltage regulator removed, and connected to a computer via Felix's FTDI connector, the average RSSI (averaged over 1,000 samples) measured while the Moteino slept is -124:

http://pastebin.com/cxjdN9S3

emjay

  • Full Member
  • ***
  • Posts: 119
  • Country: nl
Re: Real time RSSI measurement broken RFM69CW?
« Reply #99 on: February 19, 2016, 08:16:37 AM »
@WhiteHare,

Interesting results - the spread (127 <-> 118) would imply that there is still EMI injected from direct coupling to the ANT pin components. This suggests a tricky balance for setting the RSSI threshold low enough to see weak real signals versus excessive triggering from the general noise floor.
LoRa sort of side steps this by an elaborate Rx signal present detection method, at the expense of keeping the Rx section active for relatively long periods.
 

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #100 on: February 19, 2016, 11:16:44 AM »
@WhiteHare: Good work. Do you have any results when the MCU is not asleep but actively doing something, like continually polling the SPI registers?

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #101 on: February 20, 2016, 01:50:11 AM »
@WhiteHare: Good work. Do you have any results when the MCU is not asleep but actively doing something, like continually polling the SPI registers?

That's a worthwhile question, and so I just now ran that test.  Here are the results:  http://pastebin.com/VAbX37nk

In this particular case, the average RSSI (the average of a thousand measurements) with the atmega awake (specifically, polling in a tight loop for the RSSI flag to go HIGH) was -123.  However, that number is so close to the -124 average that was measured with the atmega328p asleep that I think it would take a lot more measurements to be confident as to whether or not there is really any difference between the two.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #102 on: February 20, 2016, 10:31:39 AM »
So, I finally captured the objective, which was to measure the RSSI inside a sealed metal can, while the atmega328p was sleeping (as described above), and while powered directly from battery with no voltage regulator.  What surprised me is that the average of 1,000 measurements is still -124:

http://pastebin.com/TC4fqw7v

So, I guess whatever noise is there must be coming from the rfm69 module itself?

[Edit1: Since you'll probably ask, below are the same measurements inside the sealed metal can, while powered directly from battery with no voltage regulator, but this time with the atmega awake rather than sleeping during the RSSI measurements.   The average RSSI again came out to -123:   http://pastebin.com/jV0eHp5q  ]

[Edit2: Come to think of it, I never did put the Flash Memory into Powerdown mode on any of the test runs so far.  Do you suppose it might  be having any effect?]
« Last Edit: February 20, 2016, 12:45:17 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #103 on: February 24, 2016, 10:53:49 PM »
So, to finally settle it, I did the experiment where the  Moteino with antenna solder tacked to GND is run direct from 2 AA batteries, with no voltage converter, inside a sealed metal can, and RSSI is measured while the atmega is sleeping and also while the winbond flash memory is sleeping.  In order for the flash memory to later be woken up so as to record the values, I had to add a 400K pulldown resistor between D12 and GND.  Aside from that, the hardware configuration was the same as before.

http://pastebin.com/PGcsNrr7
« Last Edit: February 25, 2016, 12:28:35 AM by WhiteHare »

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6339
  • Country: us
    • LowPowerLab
Re: Real time RSSI measurement broken RFM69CW?
« Reply #104 on: February 24, 2016, 10:56:47 PM »
Interesting. I am puzzled by the 400k pulldown. I've never had to do anything like that on a SPI device. Not sure what to say about that.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #105 on: February 25, 2016, 04:13:34 PM »
Perhaps this solves the noise mystery:

I just noticed that RSSI operates the same in both OOK and FSK modes (Figure 18 from the datasheet doesn't distinguish between them).  However, by definition of RxBw, the OOK bandwidth is half that of FSK for any given pair of mantissa and exponent, and therefore there should be less noise reflected in RSSI if measured with OOK rather than with FSK.  As a quick test, I just enabled OOK modulation, and re-ran the test measurements, and lo and behold, it does, on average, eliminate most of the remaining noise that we were puzzling over.  For convenience, I measured outside of the sealed can using the solder tacked Moteino, and the average RSSI was -126.23:

http://pastebin.com/7CcPkE0D

The OOK bandwidth is 1300Hz.

[Edit: At these low RSSI values, there's a skewing going on that's worth noting.  According to the datasheet:  "RssiValue can only be read when it exceeds RssiThreshold."  So, the atmega will never receive an interrupt on DIO0 if RSSI were to measure at -127.50.  That's why all the measured values are -127.00 and higher.  However, by adding an external timer interrupt, we could infer an RSSI value of <= -127.50 if DIO0 doesn't trigger within the expected timeframe.  I haven't done that yet, but the fact of the matter is that it takes a very noticeable amount of time to acquire the 1000 datapoints using just the DIO0 interrupt using the above congfiguration, and so I rather suspect that the majority of the time the effective RSSI using this method would show <=  -127.50.  That would be pretty awesome, wouldn't it?  For instance, if you wanted to, you might be able to do very sensitive OOK signalling (though possibly at a very slow datarate) using this method to get much better range than what's possible with normal RFM69 settings.]
« Last Edit: February 25, 2016, 05:34:45 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #106 on: February 25, 2016, 07:19:43 PM »
So, for fun, I tried measuring the 1300Hz bandwidth OOK RSSI on a non-impaired Moteino (i.e. one with a regular wire antenna), running on a battery, using the same tricks of sleeping the atmega328p and the flash memory during the RSSI measurement, and waking the atmega328p when DIO0 (mapped to RSSI) goes high to record the latched RSSI value (before it unlatches).  Again, this was outside the sealed metal can.  This time the average RSSI was higher, as you would expect, but still impressively low:  -124.56

http://pastebin.com/Y3Gaxnk3

[That compares to -118.46 average RSSI if running the same Moteino with FSK and with sensitivity boost OFF, also from battery:  http://pastebin.com/ArbC7qSX]
« Last Edit: February 25, 2016, 08:53:42 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #107 on: February 25, 2016, 09:55:59 PM »
Interesting. I am puzzled by the 400k pulldown. I've never had to do anything like that on a SPI device. Not sure what to say about that.

I switched to a 1 MegaOhm pulldown, because on a different Moteino the RFM69 would still sometimes hang during initialization if using the 400K  resistor.  So far, it seems to work.   :)

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Real time RSSI measurement broken RFM69CW?
« Reply #108 on: April 09, 2016, 12:59:55 PM »
I think I've come up with the most reliable way to measure RSSI. I had all kinds of issues and interference. But this actually works well and reliably:

To test whether there's noise at rssi value R you:

0.) Map RSSI to DIO0
1.) Set the radio to RF69_MODE_SYNTH
2.) Set threshold R as RSSITHRESH
3.) Set the radio to RF69_MODE_RX
4.) powerDown for 60ms
5.) Check whether an IRQ has hit

Do this for all values R from 255 to 150. Repeat 5 times. Now you have a good feel for the level of noise.

Instead of powerDown you can try busy waiting. Or you could even poll a RFM69 register during the wait. At least polling a register has a sizable influence on the level of noise - likely transmitted via the SPI bus. Busy waiting hardly creates any noise though.

This setup allows you to measure different power sources for their noise impact. The result is quite profound. Even an iPhone power adapter adds 23dBm in noise. Use a macbook connected USB cable as power source and it will set you back 46dBm. As a reminder: an improvement of 6 dBm about doubles the range.

Here's some of the data I've taken today. I used a long range profile with rxbw of 2.6khz. RF_TESTLNA_HIGH_SENSITIVITY is set. I used 5 iterations and listed is the highest level that got all 5 iterations hit with a RSSI irq, plus all others that are different from 0.

 328p in Powerdown:

Mac:
Apr  9 13:51:58 espgw.fritz.box  193:1 194:1 195:4 195:5

iPhone power adapter:
Apr  9 13:54:51 espgw.fritz.box  216:1 217:2 218:4 219:5

Battery:
Apr  9 13:50:06 espgw.fritz.box  239:1 240:1 241:5

328p busy wait:

Battery:
Apr  9 14:25:41 espgw.fritz.box  240:1 241:5

328p Polling RSSIThresh via SPI:

Battery:
Apr  9 14:18:34 espgw.fritz.box  233:5

I think these results are very encouraging in that they show it might still be possible to fix the AGC handling in RFM69 by lifting RSSITHRESH to a reasonable level and use timeouts to catch false triggers. I also think this shows that a noise optimized gateway can make a huge difference in supporting long range setups. Just think about it: only 1/16th of the potential range just by using an iPhone power adapter (if these numbers translate directly according to the 6dBm doubles range rule of thumb). I don't want to even speculate about what adding a Pi to the mix would do.

Joe

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #109 on: April 09, 2016, 01:33:47 PM »
This is really good work, and thank you for sharing the results.

This seems like a very practical approach, and one we should probably all be using.  We'd get even more leverage by pooling our results, because it might help identify configurations that are especially low noise.  There's a bit of gray zone though, because you're measuring the top of the noise floor rather than the bottom of the noise floor.  That's where your earlier histogram (on another thread) adds a level of insight.  So if, say, using a particular power source caused high interference 10% of the time, maybe you could still receive your packets from far away if one of the re-transmits happens during the other 90% of the time.  Of course, to save power one wants to minimize the number of re-transmits needed, but the end result may not be quite so dire.  Still, one can what-if and analyze things to death, and I think there's a lot to be said for keeping things simple so that everyone can use it.  Your approach steers clear of the grey zone, which is what we should all be aiming to do anyway.  So, bottom line: hip,  hip, hooray!

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Real time RSSI measurement broken RFM69CW?
« Reply #110 on: April 09, 2016, 01:43:09 PM »
Quote
There's a bit of gray zone though, because you're measuring the top of the noise floor rather than the bottom of the noise floor.

Not necessarily - I measure whether the noise floor hits the level during a 60ms window. Say if you have a signal source that sends once a second you'd clearly see it with this method. BTW, the fact that the floor is so narrow is partially a consequence of using the low bitrate which leads to averaging of the rssi level during detection (2 * tbit is long ).

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #111 on: April 09, 2016, 02:10:37 PM »
Quote
There's a bit of gray zone though, because you're measuring the top of the noise floor rather than the bottom of the noise floor.

Not necessarily - I measure whether the noise floor hits the level during a 60ms window. Say if you have a signal source that sends once a second you'd clearly see it with this method. BTW, the fact that the floor is so narrow is partially a consequence of using the low bitrate which leads to averaging of the rssi level during detection (2 * tbit is long ).

Ahhh, good point.

One TL;DR for the benefit of anyone who may be reading this: when it comes to using this new approach to better inform how to set your RFM69's RSSI threshold (unless you're using some kind of adaptive algorithm to set it for you), you'll want to use the same RxBw (and probably the same bitrate too(?)) as you'd normally be using.  At wider bandwidths, the amount of received noise goes up.  That may be common knowledge in some circles, but I didn't realize that's how it worked until I did the measurement experiments earlier in this thread.
« Last Edit: April 09, 2016, 02:17:39 PM by WhiteHare »

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Real time RSSI measurement broken RFM69CW?
« Reply #112 on: April 09, 2016, 02:27:43 PM »
Quote
you'll want to use the same RxBw (and probably the same bitrate too(?)) as you'd normally be using.

That's right. On the other hand the RSSI value during reception of a signal is fairly independent of the parameters as long as the signal sits firmly within rxbw. Whether I use Felix settings or the long range ones - it's not much of a difference.

So what I plan to do to see how to achieve a given communication objective is: measure noise floor and then RSSI during signal with the long range settings. Then you know how much additional noise due to broader rxbw you can tolerate and thus how high you can take the bitrate. At least that's the theory  ;)

emjay

  • Full Member
  • ***
  • Posts: 119
  • Country: nl
Re: Real time RSSI measurement broken RFM69CW?
« Reply #113 on: April 09, 2016, 09:19:57 PM »
@joelucid,

I haven't come across any BER v. input power curves for the RFM69/SX1231H, but they are published for the older RFM12B.  If you refer to page p.37 of the Si4421 spec sheet, the curves give a good guide to what improvement you would need in S/N ratio to step up to the next baud rate at constant BER.
Different chip I know, but most of this comes from the generic requirements of decoding FSK, so similar curves should apply.

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Real time RSSI measurement broken RFM69CW?
« Reply #114 on: April 10, 2016, 02:56:56 AM »
Ever wonder why the data sheet quotes the receiver sensitivity at 5khz Fdev? Now we know:

Apr 10 06:54:49 espgw.fritz.box  246:1 247:5

Another 5dBm improvement over the 1260hz Fdev setting. Increasing from there makes things worse.

This is nice - less of a need of AFC, particularly when using temp correction. I think I'll do a range test today with these settings:

         RF_BITRATEMSB_1200, RF_BITRATELSB_1200,
         RF_FDEVMSB_5000, RF_FDEVLSB_5000,
         RF_RXBW_DCCFREQ_000 | RF_RXBW_MANT_24 | RF_RXBW_EXP_5

Note that I increased DccFreq to 16% given the high modulation index.

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Real time RSSI measurement broken RFM69CW?
« Reply #115 on: April 10, 2016, 06:06:29 AM »
Just did a range test. I was limited by the terrain. 1.85km was the longest I could go. Wasn't quite line of sight either. This is with a rfm69hw, 433 mhz, both Moteino's running on batteries.

Code: [Select]
RF_BITRATEMSB_1200, RF_BITRATELSB_1200, 
RF_FDEVMSB_5000, RF_FDEVLSB_5000,
RF_RXBW_DCCFREQ_000 | RF_RXBW_MANT_24 | RF_RXBW_EXP_5,
RF_TESTLNA_HIGH_SENSITIVITY, RF_PACKET1_FORMAT_VARIABLE | RF_PACKET1_DCFREE_WHITENING |   RF_PACKET1_CRC_ON | RF_PACKET1_CRCAUTOCLEAR_ON | RF_PACKET1_ADRSFILTERING_OFF

In all the excitement I had a couple of errors in the earlier posts. rssiThresh is measured in 1/2 dBm steps. So the last improvement only added 3 dBm. And the iPhone charger only costs 12, for a 1/4th reduction in range.

Joe
« Last Edit: April 10, 2016, 06:15:02 AM by joelucid »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #116 on: April 10, 2016, 09:32:35 AM »
1.85km was the longest I could go.

Was that 1.85km with a BER of <1%, or was that the range at which you could just barely receive any packets at all? 

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Real time RSSI measurement broken RFM69CW?
« Reply #117 on: April 10, 2016, 10:52:05 AM »
Quote
Was that 1.85km with a BER of <1%, or was that the range at which you could just barely receive any packets at all?

My problem is finding an area with line of sight for testing. Just did another test and got 2.1km. But still some trees etc in the way. So what happens is when you have a spot where there's reception at all I see just about every packet (and I uses CRC so that means no bit errors). If too much is in the way nothing comes through.

I take that as indication that with line of sight there's still room for substantial improvement.

But not today - my feet hurt  ;)

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Real time RSSI measurement broken RFM69CW?
« Reply #118 on: April 10, 2016, 02:10:14 PM »
This is too cool not to share. Packet reception at an RSSI of -121. That's why you need low noise receivers:

Code: [Select]
Apr 10 19:47:00 espgw.lx  [254] [RX_RSSI:-56,1,8,45]
Apr 10 19:47:00 espgw.lx  !RSSI:-120
Apr 10 19:47:03 espgw.lx  [254] [RX_RSSI:-55,1,8,45]
Apr 10 19:47:03 espgw.lx  !RSSI:-118
Apr 10 19:47:06 espgw.lx  [254] [RX_RSSI:-56,1,8,45]
Apr 10 19:47:06 espgw.lx  !RSSI:-117
Apr 10 19:47:09 espgw.lx  [254] [RX_RSSI:-56,1,8,45]
Apr 10 19:47:09 espgw.lx  !RSSI:-117
Apr 10 19:47:12 espgw.lx  [254] [RX_RSSI:-56,1,8,45]
Apr 10 19:47:12 espgw.lx  !RSSI:-121
Apr 10 19:47:16 espgw.lx  [254] [RX_RSSI:-56,1,8,45]
Apr 10 19:47:16 espgw.lx  !RSSI:-120
Apr 10 19:47:22 espgw.lx  [254] [RX_RSSI:-55,1,8,45]
Apr 10 19:47:22 espgw.lx  !RSSI:-117

Joe

PS: The !RSSI entries count. The [254] entries are from my main gateway. I use a battery powered Moteino as receiver for this test to enable these low noise measurements. Results are then forwarded to the main gw for logging purposes.
« Last Edit: April 10, 2016, 02:13:42 PM by joelucid »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #119 on: April 10, 2016, 02:51:49 PM »
Is it saying that the battery powered moteino is receiving packets from the espgw at an RSSI of -56, and then it sends that RSSI Rx info in a packet back to the espgw, which receives it at an RSSI of -121?

Or is it saying that the battery powered moteino is receiving packets at an RSSI of -56 at a time (just before or after) that the background noise level (!RSSI) is -121?

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Real time RSSI measurement broken RFM69CW?
« Reply #120 on: April 10, 2016, 02:57:38 PM »
It says that the battery powered moteino receives a packet from a remote battery powered moteino with an RSSI during reception of -121. The local battery powered moteino then sends the !RSSI: xxx log request to the espgw which logs it using syslog to my server.

So yes as I said and it's hard to believe: packet reception at a signal level of -121 dBm.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #121 on: April 10, 2016, 04:05:43 PM »
Ever wonder why the data sheet quotes the receiver sensitivity at 5khz Fdev? Now we know:

Apr 10 06:54:49 espgw.fritz.box  246:1 247:5

Another 5dBm improvement over the 1260hz Fdev setting. Increasing from there makes things worse.

This is nice - less of a need of AFC, particularly when using temp correction. I think I'll do a range test today with these settings:

         RF_BITRATEMSB_1200, RF_BITRATELSB_1200,
         RF_FDEVMSB_5000, RF_FDEVLSB_5000,
         RF_RXBW_DCCFREQ_000 | RF_RXBW_MANT_24 | RF_RXBW_EXP_5

Note that I increased DccFreq to 16% given the high modulation index.

I suppose it's no accident that the chip powers up to a default setting of FDEV=5Khz.   ;)

TomWS

  • Hero Member
  • *****
  • Posts: 1925
Re: Real time RSSI measurement broken RFM69CW?
« Reply #122 on: April 10, 2016, 08:28:58 PM »
It says that the battery powered moteino receives a packet from a remote battery powered moteino with an RSSI during reception of -121. The local battery powered moteino then sends the !RSSI: xxx log request to the espgw which logs it using syslog to my server.

So yes as I said and it's hard to believe: packet reception at a signal level of -121 dBm.
Now what would be REALLLLLLLY cool is if we could get these kind of numbers with the Nifty(R) device!

Nice work!

Tom

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Real time RSSI measurement broken RFM69CW?
« Reply #123 on: April 11, 2016, 02:47:46 AM »
Quote
Now what would be REALLLLLLLY cool is if we could get these kind of numbers with the Nifty(R) device!

It's as if you could read my mind  ;)

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #124 on: April 13, 2016, 01:11:15 AM »
This is too cool not to share. Packet reception at an RSSI of -121. That's why you need low noise receivers:
Code: [Select]
Apr 10 19:47:12 espgw.lx  [254] [RX_RSSI:-56,1,8,45]
Apr 10 19:47:12 espgw.lx  !RSSI:-121

The issue I have with the high sensitivity setting is that, in the general case, it seems to require that my code be prescient as to when it needs to be turned on.  I do see  that it might help at the margin for statically mounted devices that communicate on a known timetable.

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Real time RSSI measurement broken RFM69CW?
« Reply #125 on: April 13, 2016, 01:53:25 AM »
Quote
The issue I have with the high sensitivity setting is that, in the general case, it seems to require that my code be prescient as to when it needs to be turned on.  I do see  that it might help at the margin for statically mounted devices that communicate on a known timetable.

True. But there are some scenarios that ONLY work with these settings so they are necessary.

Since one usually has multiple clients you either have to have one gw per setting you use. Or several settings share one radio. In the second case you have to manage which setting gets used when. That requires synchronized clients, so an RTC of some sort or at least a calibrated WDT (haven't tried that yet).

One thing I liked about the esp8266 gateway idea is that it's so cheap you can just have one for each setting your environment requires. The clients could automatically talk to the right one similar to Tom's tx power code.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #126 on: April 22, 2016, 03:13:08 PM »
I decided to revisit an earlier sketch, but this time I set the RSSI threshhold to 180 (-90db) instead of 255, because 255 was when I was trying to measure anything that was in the air from one moment to the next.

Surprisingly, once the first RSSI threshhold is met, further RSSI measurements seem to just keep rolling along, irrespective of the higher threshhold.  In one of the cases (below), it even seems to continue ignoring the higher RSSI threshhold past one of the restarts of Rx.  But then on the next cycle it waits for RSSI to pass the threshhold again.  Surprisingly inconsistent!


http://pastebin.com/TKTpv1Kj
« Last Edit: April 22, 2016, 03:34:14 PM by WhiteHare »

ChemE

  • Sr. Member
  • ****
  • Posts: 419
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #127 on: March 20, 2018, 07:23:39 AM »
Necropost warning!  I just reread this thread in great detail but I'm curious if anyone ever got anywhere with RSSI.  Felix's library seems to sample RSSI in the interrupt routine just after PacketReady goes high and triggers INT0 and seems to give pretty stable results from packet to packet.  Oddly, when I do the same in my own interrupt handler I will get -27dBm on one packet and -85dBm on the next.  This is from two RFM69W Motes with 1/4 wave antennas sitting 4" from each other and one broadcasting at +13dB.  My own radio library is inching ever closer to version 1.0 and this is something I need to nail before it will be of much use to anyone.

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Real time RSSI measurement broken RFM69CW?
« Reply #128 on: March 20, 2018, 05:01:49 PM »
In my code which is written from scratch and doesn't use any libraries as such I read the RSSI immediately I get a PayloadReady indication as the very first thing it does, i.e. before I read the data out of the FIFO, because as soon as the data is read out the RX can restart and the RSSI can get overridden. I don't have any trouble with that at all. Maybe worth moving the RSSI read to much earlier on in the ISR, it appears to be read after the FIFO is emptied and the device put back into RX mode in the library. It maybe a timing issue with your code compared to Felix's.

Mark.

ChemE

  • Sr. Member
  • ****
  • Posts: 419
  • Country: us
Re: Real time RSSI measurement broken RFM69CW?
« Reply #129 on: March 20, 2018, 10:14:03 PM »
Thanks Mark, it helps to know you've also got consistent results using the same ISR flow and interrupt.  It may very well be because my "network" right now is 2 motes on a USB hub 4" from each other.  Surely there are plenty of noise paths between the two.  I'll move one to battery power and see if that doesn't resolve my issue.  I did spend some time fooling with entering the ISR on SyncAddress and I've even been able to pull data out of the FIFO as it is filling but that made things even more complicated!