Author Topic: Real time RSSI measurement broken RFM69CW?  (Read 47287 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: 1300
  • 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: 1300
  • 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: 1300
  • 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: 1300
  • 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 »