RFM95 Lora radios not responding to INTERNAL (presentation and reboot) requests

[doug]

Hi

A bit of a weird one I have just changed my radios from the RFM69HCW's to the RFM95 Lora radios and am working with the serial gateway connected to a windows PC running MYSController and have a single node sending temp data.

When the node boots up it registers with MYSController presents the sensor information and starts reporting the temp every 5 seconds sleeping in between. I have put in a heartbeat request then a delay before sleeping to wait for any commands from MySController this is set at 500 ms but I have tried up to 5000 ms to allow for the longer TX times of Lora.

This setup when used with the RFM69HCW radios the INTERNAL reboot and presentation requests are serviced by the node however wen using the RFM95 radios they are not.

I am using the RFM95 radios without the reset connected and DIO0 on interrupt 0 pin 2 and DIO1 and DIO2 not connected.

Messages from the node to the gateway work well and are received every 5 seconds.

Swapping the node hardware around between node and gateway also has the same issues so it is not a hardware fault.

Debug on the node dosen't see any INTERNAL messages received.

Any Ideas or suggestions on what to try next would be appreciated

[mfalkvidd]

@doug which spreading factor are you using? I am not sure but you might need to increase RFM95_RETRY_TIMEOUT_MS in RFM95.h

Do you get anyting interesting when enabling rfm95 debug?
MY_DEBUG_VERBOSE_RFM95

[doug]

With MY_DEBUG_VERBOSE_RFM95 set it looks like something is being received not sure I understand it though!!

I have set both radios up as below so spreading factor is default of 128 and I am not sleeping the node just wait(10000) in the loop

#define MY_RADIO_RFM95
#define MY_RFM95_MODEM_CONFIGRUATION RFM95_BW125CR45SF128
#define MY_RFM95_TX_POWER 13 // max is 23
//#define MY_RFM95_ATC_MODE_DISABLED
//#define MY_RFM95_ATC_TARGET_RSSI (-60)
//#define MY_RFM95_FREQUENCY (928.5f)

//#define MY_RFM95_RST_PIN 6
#define MY_RFM95_IRQ_PIN 2 // IRQ
#define MY_RFM95_SPI_CS 10 // NSS

This is the debug output from the node when it is just sending a message

163622 TSF:MSG:SEND,1-1-0-0,s=1,c=1,t=48,pt=0,l=16,sg=0,ft=0,st=OK:234,2.51,18.75,0
163645 RFM95:SWR:SEND TO=0,RETRY=0
163766 RFM95:SWR:ACK FROM=0,SEQ=58,RSSI=-28,SNR=10
163778 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:154530
175908 RFM95:SWR:SEND TO=0,RETRY=0
176046 RFM95:SWR:ACK FROM=0,SEQ=59,RSSI=-27,SNR=9

This is the debug output of the node when I have sent an internal presentation request

226625 RFM95:SWR:SEND TO=0,RETRY=0
226762 RFM95:SWR:ACK FROM=0,SEQ=67,RSSI=-28,SNR=9
226775 TSF:MSG:SEND,1-1-0-0,s=1,c=1,t=48,pt=0,l=16,sg=0,ft=0,st=OK:233,2.49,18.50,0
226797 RFM95:SWR:SEND TO=0,RETRY=0
227309 !RFM95:SWR:NACK
227315 RFM95:PTX:LEVEL=5
227321 RFM95:SWR:SEND TO=0,RETRY=1
227885 !RFM95:SWR:NACK
227891 RFM95:PTX:LEVEL=5
227897 !TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=NACK:217684
240027 RFM95:SWR:SEND TO=0,RETRY=0

[doug]

Looks like I have managed to work this out it seems to be a case of the radios transmitting over each other.

If smartSleep is used then the heartbeat transmits over the something so rather than smart sleep i have used

  wait(1000);
  sendHeartbeat();
  wait(1000);
  sleep(digitalPinToInterrupt(INTERRUPT_PIN),FALLING,0);

Very hungry on power though. I know work was being done on smartsleep for v2.1.1 I'll give that a go