[Solved] Small problem with getting RSSI in an otherwise working RFM95 setup

Joost

Hi everybody,

I'd like to send RSSI data to the controller (Home Assistant on a Raspi 3 with an Arduino Pro Mini USB Gateway; both node and GW on lib 2.3.2; RFM95 transceivers). I used the example sketch with just minimal additions (as it does not work for me out of the box):

// Enable debug prints
#define MY_DEBUG
#define MY_DEBUG_VERBOSE_RFM95

// Define a lower baud rate for Arduinos running on 8 MHz (Arduino Pro Mini 3.3V & SenseBender)
#if F_CPU == 8000000L
#define MY_BAUD_RATE 38400
#endif

// RFM95
#define MY_RADIO_RFM95
#define MY_RFM95_ATC_TARGET_RSSI_DBM (-70)  // target RSSI -70dBm
#define MY_RFM95_MAX_POWER_LEVEL_DBM (10)   // max. TX power 10dBm = 10mW
//#define MY_RFM95_ATC_MODE_DISABLED

#include <MySensors.h>

// ID of the sensor child
#define CHILD_ID_UPLINK_QUALITY (0)
#define CHILD_ID_TX_LEVEL       (1)
#define CHILD_ID_TX_PERCENT     (2)
#define CHILD_ID_TX_RSSI        (3)
#define CHILD_ID_RX_RSSI        (4)
#define CHILD_ID_TX_SNR         (5)
#define CHILD_ID_RX_SNR         (6)


// Initialize general message
MyMessage msgTxRSSI(CHILD_ID_TX_RSSI, V_CUSTOM);
MyMessage msgRxRSSI(CHILD_ID_RX_RSSI, V_CUSTOM);
MyMessage msgTxSNR(CHILD_ID_TX_SNR, V_CUSTOM);
MyMessage msgRxSNR(CHILD_ID_RX_SNR, V_CUSTOM);
MyMessage msgTxLevel(CHILD_ID_TX_LEVEL, V_CUSTOM);
MyMessage msgTxPercent(CHILD_ID_TX_PERCENT, V_CUSTOM);
MyMessage msgUplinkQuality(CHILD_ID_UPLINK_QUALITY, V_CUSTOM);

void setup()
{
}


void presentation()
{
	// Send the sketch version information to the gateway and controller
	sendSketchInfo("ATC", "1.0");

	// Register all sensors to gw (they will be created as child devices)
	present(CHILD_ID_UPLINK_QUALITY, S_CUSTOM, "UPLINK QUALITY RSSI");
	present(CHILD_ID_TX_LEVEL, S_CUSTOM, "TX LEVEL DBM");
	present(CHILD_ID_TX_PERCENT, S_CUSTOM, "TX LEVEL PERCENT");
	present(CHILD_ID_TX_RSSI, S_CUSTOM, "TX RSSI");
	present(CHILD_ID_RX_RSSI, S_CUSTOM, "RX RSSI");
	present(CHILD_ID_TX_SNR, S_CUSTOM, "TX SNR");
	present(CHILD_ID_RX_SNR, S_CUSTOM, "RX SNR", true); //so bekommt man ein ACK zurück, wird über void receive verarbeitet (funktioniert)
}

void loop()
{
	Serial.println(transportGetSignalReport(SR_RX_RSSI));
	Serial.println(transportGetSignalReport(SR_UPLINK_QUALITY));
	// send messages to GW
	send(msgUplinkQuality.set(transportGetSignalReport(SR_UPLINK_QUALITY)));
	send(msgTxLevel.set(transportGetSignalReport(SR_TX_POWER_LEVEL)));
	send(msgTxPercent.set(transportGetSignalReport(SR_TX_POWER_PERCENT)), true);
	// retrieve RSSI / SNR reports from incoming ACK
	send(msgTxRSSI.set(transportGetSignalReport(SR_TX_RSSI)));
	send(msgRxRSSI.set(transportGetSignalReport(SR_RX_RSSI)));
	send(msgTxSNR.set(transportGetSignalReport(SR_TX_SNR)));
	send(msgRxSNR.set(transportGetSignalReport(SR_RX_SNR)));
	// wait a bit
	sleep(10000);
}

void receive(const MyMessage &message) {
  Serial.print("Incoming message for child: "); Serial.println(message.sensor);
  if (message.isAck() ) {//&& message.type == V_TRIPPED) {  // Test if ack received and for which type of msg, you could also test for which child id
     Serial.println("This is an ack from gateway");
     // set your "flag" ack variable to true here. Test it in your retry loop and reset it to false
  }
}

Unfortunately data retrieved by transportGetSignalReport(X) is "0". Here is the log with additional RFM95 debug output:


0
0
72869 RFM95:SWR:SEND,TO=0,SEQ=200,RETRY=0
72974 RFM95:SWR:ACK FROM=0,SEQ=201,RSSI=-30
72986 TSF:MSG:SEND,131-131-0-0,s=0,c=1,t=48,pt=2,l=2,sg=0,ft=0,st=OK:0
73005 RFM95:SWR:SEND,TO=0,SEQ=201,RETRY=0
73111 RFM95:SWR:ACK FROM=0,SEQ=202,RSSI=-31
73121 TSF:MSG:SEND,131-131-0-0,s=1,c=1,t=48,pt=2,l=2,sg=0,ft=0,st=OK:0
73142 RFM95:SWR:SEND,TO=0,SEQ=202,RETRY=0
73246 RFM95:SWR:ACK FROM=0,SEQ=203,RSSI=-31
73259 TSF:MSG:SEND,131-131-0-0,s=2,c=1,t=48,pt=2,l=2,sg=0,ft=0,st=OK:0
73277 RFM95:SWR:SEND,TO=0,SEQ=203,RETRY=0
73289 !TSF:MSG:SEND,131-131-0-0,s=3,c=1,t=48,pt=2,l=2,sg=0,ft=0,st=NACK:0
73310 RFM95:SWR:SEND,TO=0,SEQ=203,RETRY=0
73502 !RFM95:SWR:NACK
73578 RFM95:SWR:SEND,TO=0,SEQ=204,RETRY=1
73777 !RFM95:SWR:NACK
73820 RFM95:SWR:SEND,TO=0,SEQ=204,RETRY=2
73996 !RFM95:SWR:NACK
74082 RFM95:SWR:SEND,TO=0,SEQ=204,RETRY=3
74276 !RFM95:SWR:NACK
74326 RFM95:SWR:SEND,TO=0,SEQ=204,RETRY=4
74496 RFM95:SWR:ACK FROM=0,SEQ=204,RSSI=-31
74508 TSF:MSG:SEND,131-131-0-0,s=4,c=1,t=48,pt=2,l=2,sg=0,ft=1,st=OK:0
74526 RFM95:SWR:SEND,TO=0,SEQ=204,RETRY=0
74631 RFM95:SWR:ACK FROM=0,SEQ=205,RSSI=-31
74643 TSF:MSG:SEND,131-131-0-0,s=5,c=1,t=48,pt=2,l=2,sg=0,ft=0,st=OK:0
74661 RFM95:SWR:SEND,TO=0,SEQ=205,RETRY=0
74768 RFM95:SWR:ACK FROM=0,SEQ=206,RSSI=-31
74778 TSF:MSG:SEND,131-131-0-0,s=6,c=1,t=48,pt=2,l=2,sg=0,ft=0,st=OK:0
74799 MCO:SLP:MS=10000,SMS=0,I1=255,M1=255,I2=255,M2=255
74813 TSF:TDI:TSL
74819 RFM95:RSL
74823 MCO:SLP:WUP=-1
74829 TSF:TRI:TSB
74833 RFM95:RSB
0
0
74840 RFM95:SWR:SEND,TO=0,SEQ=206,RETRY=0
74854 !TSF:MSG:SEND,131-131-0-0,s=0,c=1,t=48,pt=2,l=2,sg=0,ft=0,st=NACK:0
74872 RFM95:SWR:SEND,TO=0,SEQ=206,RETRY=0
74979 RFM95:SWR:ACK FROM=0,SEQ=207,RSSI=-31
74991 TSF:MSG:SEND,131-131-0-0,s=1,c=1,t=48,pt=2,l=2,sg=0,ft=1,st=OK:0
75010 RFM95:SWR:SEND,TO=0,SEQ=207,RETRY=0
75114 RFM95:SWR:ACK FROM=0,SEQ=208,RSSI=-31
75126 TSF:MSG:SEND,131-131-0-0,s=2,c=1,t=48,pt=2,l=2,sg=0,ft=0,st=OK:0
75145 RFM95:SWR:SEND,TO=0,SEQ=208,RETRY=0
75159 !TSF:MSG:SEND,131-131-0-0,s=3,c=1,t=48,pt=2,l=2,sg=0,ft=0,st=NACK:0
75177 RFM95:SWR:SEND,TO=0,SEQ=208,RETRY=0
75354 !RFM95:SWR:NACK
75397 RFM95:SWR:SEND,TO=0,SEQ=209,RETRY=1
75567 !RFM95:SWR:NACK
75630 RFM95:SWR:SEND,TO=0,SEQ=209,RETRY=2
75812 !RFM95:SWR:NACK
75909 RFM95:SWR:SEND,TO=0,SEQ=209,RETRY=3
76038 !RFM95:SWR:NACK
76113 RFM95:SWR:SEND,TO=0,SEQ=209,RETRY=4
76265 RFM95:SWR:ACK FROM=0,SEQ=209,RSSI=-31
76275 TSF:MSG:SEND,131-131-0-0,s=4,c=1,t=48,pt=2,l=2,sg=0,ft=1,st=OK:0
76296 RFM95:SWR:SEND,TO=0,SEQ=209,RETRY=0
76400 RFM95:SWR:ACK FROM=0,SEQ=210,RSSI=-31
76412 TSF:MSG:SEND,131-131-0-0,s=5,c=1,t=48,pt=2,l=2,sg=0,ft=0,st=OK:0
76431 RFM95:SWR:SEND,TO=0,SEQ=210,RETRY=0
76535 RFM95:SWR:ACK FROM=0,SEQ=211,RSSI=-31
76548 TSF:MSG:SEND,131-131-0-0,s=6,c=1,t=48,pt=2,l=2,sg=0,ft=0,st=OK:0
76566 MCO:SLP:MS=10000,SMS=0,I1=255,M1=255,I2=255,M2=255
76582 TSF:TDI:TSL
76587 RFM95:RSL

Here I see that in the debug output of the RFM95 driver, the RSSI is read and printed, alternating slightly over time from -29 to -31, seeming like valid data. But reading it in the sketch with transportGetSignalReport() gives me zeroes for all fields.

Anyone with an idea what might be going on?

Thanks very much for all your work & help with this great project,

Joost

Joost

Hi,

maybe anyone around here is running a RFM95 setup and could possibly test if they get credible output out of transportGetSignalReport(X) with the RFM95 driver?
Any other ideas?

Thanks everyone for working on / helping with MySensors!

tekka

@Joost did you set

#define MY_SIGNAL_REPORT_ENABLED

to enable the signal report functionality as documented here?

Joost

@tekka
Hi, thanks a ton, this was the missing piece! Working great now!

I started with the "official" example sketch out of the MySensors codebase

https://github.com/mysensors/MySensors/blob/master/examples/RFM69_RFM95_ATC_SignalReport/RFM69_RFM95_ATC_SignalReport.ino ,

where I did not see any reference to

#define MY_SIGNAL_REPORT_ENABLED

Did I overlook something or is this example sketch not working on its own in the current form?

Thanks again very much for your help, best regards,

Joost

tekka

PR submitted: https://github.com/mysensors/MySensors/pull/1392

Joost

@tekka Thanks a lot!

[Solved] Small problem with getting RSSI in an otherwise working RFM95 setup

13

11.7k

11.2k

113.1k