There's a way to reset the rf module? #92

marcolettieri · 2016-03-29T09:38:08Z

When the rf module is high stressed and/or far from other nodes the checkmessagereceived return ever false and i can not send on my rf module.
But if turn off and on the device it start work again.
I've debugged carefully my sketch but it seems to be the library/hardware no responding.
There's so a way to reset the rf module without reboot the device?

glynhudson · 2016-03-29T12:15:12Z

I have also noticed this issue. Calling rf12_initialize resets the module. We do this every 60s:

    if ((now - last_rf_rest) > RF_RESET_PERIOD) {
      rf12_initialize(nodeID, RF_freq, networkGroup);                             // Periodically reset RFM69CW to keep it alive :-( 
    }

https://github.com/openenergymonitor/emonpi/blob/rf_hang/Atmega328/emonPi_RFM69CW_RF12Demo_DiscreteSampling/emonPi_RFM69CW_RF12Demo_DiscreteSampling.ino#L250

I would love to get to the bottom of why such drastic action is required :-(
However resetting does not take a long time and seems to have not detrimental effects on receiving or transmitting periodic RF data

marcolettieri · 2016-03-29T12:50:47Z

60s??? wow...
the issue happens to us after a long time, randomly, but, if happens, usually after 2-3 days of continuous use. often after a few minutes / hours / day it back to work or is definitelly frozen.
Reinitializing every 60 seconds has resolved the issue?
how frequently do you send RF data?

I tried to do the rf12_initialize if i don't receive messages from minutes. On your experience try to do rf12_initalize when the device is in this undefined status is useless?

I tried the following without success..

   if(lastMessageTime>0 && millis()-lastMessageTime>10000){
       uint16_t spi_control = rf12_control(0x0000);
       if(spi_control==65535 || spi_control==0){
         Serial.println("Reitializing RF Module...");
        rf12_initialize(NODEID, RF12_433MHZ, NETWORKID, 0x0640);
        rf12_control(0xC623);
        rf12_control(0x9820);
        rf12_control(getChannelByID(channelID)); 
     }
   }

   if((lastMessageTime>0 && millis()-lastMessageTime>30000) || (lastMessageSentTime>0 && millis()-lastMessageSentTime>30000)){
       lastMessageTime=millis()-10000;
       lastMessageSentTime=millis()-10000;
       lastReceivedMessageID=0;
       Serial.println("RESTORE RF");
       rf12_recvDone();
       rf12_sleep(RF12_SLEEP);
       delay(500);
       rf12_sleep(RF12_WAKEUP);
       delay(100);
       rf12_recvDone();
       rf12_initialize(NODEID, RF12_433MHZ, NETWORKID, 0x0640);
       rf12_control(0xC623);
       rf12_control(0x9820);
       rf12_control(getChannelByID(channelID));
       rf12_recvDone();
   }

jcw · 2016-03-29T12:53:46Z

I would love to get to the bottom of why such drastic action is required :-(

Same here - that's the RF12 driver in native ("classic") mode? I've never seen this before...

glynhudson · 2016-03-29T13:09:18Z

It's running in RFM69CW mode:

# define RF69_COMPAT 1

60's is probably an overkill, issue only occurs occasionally every few days.

marcolettieri · 2016-03-29T14:52:24Z

So the only solution for you is a reinitialize every x seconds/minutes?

JohnOH · 2016-03-29T15:15:41Z

@lettierimarco would you be willing to give my test code a spin. It is derived from jeelib and a full git replacement: https://github.com/jcw/jeelib/tree/RFxConsole

marcolettieri · 2016-03-29T15:21:24Z

@JohnOH sure, but i repeat, the issue is quietly randomly, so difficult to reproduce.
I've tryied to use your derived, unfortunately my RF module seems not initializing... tomorrow i'll try a merge for vital params

JohnOH · 2016-03-29T16:15:48Z

I may have incorrectly assumed you were having this problem with RFM69CW hardware. My adjustments in the RFM69 code are quite extensive. My tweaks for the RFM12B are indeed trivial.

FWIW I have not seen anything to concern me while operating RFM12B devices.

glynhudson · 2016-03-29T18:32:05Z

Hi John,

Have you got a summary of changes you have made to the default jeelib in your branch?

sent from my mobile device
On 29 Mar 2016 17:15, "JohnOH" notifications@github.com wrote:

I may have incorrectly assumed you were having this problem with RFM69CW
hardware. My tweaks for the RFM12B are indeed trivial. I have not seen
anything to concern me while operating RFM12B devices.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#92 (comment)

JohnOH · 2016-03-29T21:32:48Z

I'm afraid I don't have a summary the changes evolved or quite a long period. A diff of the five RF69* files will show them.

marcolettieri · 2016-03-30T07:26:22Z

I've compiled your rfm12.cpp without # define RF69_COMPAT 1, my RF works but i don't know if my issue will reproduce again...
Any idea why for my RFM12B ? Can i test something for a thoroughly investigate ? Has sense to reinitialize the rf12 module every 60seconds?

marcolettieri · 2016-03-30T08:00:49Z

I've forked jeelib and commit some little change i've done: https://github.com/lettierimarco/jeelib

jcw · 2016-04-08T12:12:19Z

I'd like to look into this issue - is there any more info which might help narrow this down?

PS. Strictly speaking, the answer to this issue is "yes": call rf12_initialize, but that's a workaround.

jcw · 2016-04-08T15:07:23Z

@glynhudson @lettierimarco - are we mixing RF69 and RF12 issues in this discussion by any chance? if so, please consider splitting off a separate one - I really want to help get to the bottom of this, but I'm going to have a very hard time if two problems are being mixed up...

marcolettieri · 2016-04-08T17:45:19Z

My issue happens using rf12.

jcw · 2016-04-08T23:01:22Z

I have just checked in two changes to the RF69 compat mode driver, i.e. inter-operating with an RF12 driver at the other end, which should substantially improve bad packet rejection and reduce dead-time - i.e. better noise rejection and fewer missed packets - with a huge thank-you to Martyn and John.

This change does not affect the RF12 driver side of things.

JohnOH · 2016-04-09T15:48:04Z

@lettierimarco can you post your full sketch with an indication as to where the code is returning permanent false (checkmessagereceived).

marcolettieri · 2016-04-09T16:57:42Z

@JohnOH I only supposed this... I can't reproduce the issue programmatically but it happens.
I don't know if it could be connected to RF69 issue or not.
Now I'm trying to detect in rf12_interrupt the FIFO Overflow bit and the power reset bit. I hope this can explain why my RF stop receive and sending until I restart my device.
Sadly no one of them verified since I started the test (a week ago).

JohnOH · 2016-04-09T17:02:44Z

I don't think your issue is connected with the RF69 issue.
Do you use rf12_canSend in your sketch?
Are you unable to post a link to your sketch here?

glynhudson · 2016-04-10T13:46:53Z

@jcw I am using RFM69CW with # define RF69_COMPAT 1. Sounds good, I will setup a test including your latest commits 6f1af25

marcolettieri · 2016-04-12T13:40:43Z

void setup() {
  cli();  
  wdt_enable(WDTO_8S); 
  sei();
  wdt_reset();
  Serial.begin(SERIAL_BAUD);
  Serial.println("---> SETUP BEGIN");
  rst.debounceTime = 10;
  rst.heldDownTime = DEFAULT_HOLD_BUTTON_TIME;
  rst.multiclickTime = 50;
  send_buffer.init(200);
  send_buffer.clear();
  banList.init(32);
  banList.clear();
  pinMode(LINK_LED, OUTPUT);
  pinMode(TX_RX_LED, OUTPUT);
  pinMode(IDENTIFY_LED, OUTPUT);
  pinMode(RELAY_ON_LED, OUTPUT);
  pinMode(RELAYPIN, OUTPUT);
  pinMode(A6, INPUT_PULLUP);
  pinMode(13, INPUT_PULLUP);
  pinMode(12, INPUT_PULLUP);

  digitalWrite(LINK_LED, LOW);
  digitalWrite(TX_RX_LED, LOW);
  digitalWrite(IDENTIFY_LED, LOW);
  digitalWrite(RELAY_ON_LED, LOW);

  Serial.println("Initializing threads...");

  PT_INIT(&powerMetering_pt);
  PT_INIT(&linkCheckVerifier_pt);
  PT_INIT(&configManager_pt);


  wdt_reset();

  Serial.println("Initializing RF Module...");
  rfReinitliazing =millis();
  //RFM12 initialization
  uint16_t channel = getChannelByID(channelID);
  rf12_initialize(NODEID, RF12_433MHZ, NETWORKID, channel);
  Serial.print("----> Setting RF Frequency ");Serial.print("(");Serial.print(channelID);Serial.print(") :");Serial.println(getChannelByID(channelID),HEX);
  wdt_reset();
  Serial.println("SETUP DONE! Firmware version: "__DATE__" "__TIME__);
  bootTime = millis(); 
}

void loop(){
  wdt_reset();

  //Verifica la pressione del pulsante di reset/accensione
  rst.Update();
  if(waitingConfiguration){
    setupConfiguration();
  }else {
        //Controlla il LINK LED in base al successo di validazione
        if(mainRoute.verified) {
          digitalWrite(LINK_LED,HIGH);
        } else {
          digitalWrite(LINK_LED,LOW);
        }
        wdt_reset();

        //check if a message arrived...
        checkMessageReceived();

        //Send RF Commands
        checkMessageToSend();

       wdt_reset();  
       if(lastMessageTime>0 && millis()-lastMessageTime>10000){
           //Serial.print("SERIAL :");
           //Serial.println(rf12_control(0x0000),DEC);
           uint16_t spi_control = rf12_control(0x0000);
           if(spi_control==65535 || spi_control==0){
            //RFM12 initialization
            uint16_t channel = getChannelByID(channelID);
            rf12_initialize(NODEID, RF12_433MHZ, NETWORKID, 0x0640);
         }
       }
    }
}


static void checkMessageReceived(){
  if(rf12_recvDone()) {
    if(rf12_crc == 0) {
        //manage packet
    }
  }
}

static void checkMessageToSend() {
  boolean ableToSend = false;
  ableToSend = (mainRoute.verified && tokenAcquired) || (!mainRoute.verified);

  if(send_buffer.getSize() > 0 && ableToSend) { 
    if(rf12_canSend()) {
      //populate buffer to send
      delay(10);
      rf12_sendStart(toSend.jeeDest, toSend.bytes, totLen);
      rf12_sendWait(0);
    }
  }
}

in rf12.cpp i'm trying this without success until now:

static void rf12_interrupt () {
       uint16_t r = rf12_xferSlow(cmd);
       if(r&0x2000)
           //manage Fifo Overflow occured
       else if(r&0x4000)
          //manage Power Reset occured

...

JohnOH · 2016-04-12T14:29:06Z

Might you try adding an } else { error-message } to the

if(rf12_canSend()) {
  //populate buffer to send
  delay(10);
  rf12_sendStart(toSend.jeeDest, toSend.bytes, totLen);
  rf12_sendWait(0);
} else {
    print an informative message
}

marcolettieri · 2016-04-12T14:35:20Z

I've already done this debug in past.
I've a TDM of about 200 ms so is probably that canSend is false sometimes but is not a problem.
Like i told in first post the problem is that when the issue happens i can't receive and send but the firmware is running.
My first idea was that there is a interference on the RF but the issue happens, in a environment of 5 devices, only to one.
After the issue happens sometimes the device can restore the RF in some minutes, hours or never more.
So after depth check on my hardware and sketch i'm now analyzing the rf12 library.
I've tested if there is some FIFO or Power issue with the improvment i've posted before since the rf12 library doesn't check this interrupt bit.

JohnOH · 2016-04-12T16:02:24Z

I am sorry to have covered old ground for you. I thought you may be locking up where rf12_canSend never returns true. In my case this has been an issue whereby the RF noise floor was never quiet enough for rf12_canSend to return true. I don't have any further ideas for you at this point.

glynhudson · 2016-04-18T21:43:46Z

So far so good 3 days and counting....

I have setup a test using latest JeeLib. If anyone is interested I have experimented with git submodules this has allowed me to associate the github libs (at a specific point) used in my project within the project repo itself without loosing association with the original lib repo.

Using this method of lib management has been fantastic for this example: I created a new dev branch 'rf-test' and in that branch fast-forwarded jeelib to the latest version and made the changes to code required for the test.

openenergymonitor/emonpi@e96cb04

I have documented using sub modules here:

https://github.com/openenergymonitor/emonpi/tree/master/firmware/libraries

glynhudson · 2016-04-28T15:50:27Z

Still looking good 👍

jcw · 2016-04-28T16:24:13Z

Great - declare victory before it decides to change its mind! :)

this change also sends out one more 0xAA preamble byte

… radio freezes after ~2days of operation. unoserver2: Reset RFM69 if the time of last recvd pkt > 10sec. This reset is a workaround for a JeeLib issue due to which the radio freezes about ~2 days of continuous operation (see jeelabs/jeelib#92) NaTopic2: Don't add packets from node_id=0 to history. PktHndlr: Correctly handle packets from node_id=0; naarad: Set packet history to 4*24hrs.

…est reçu pendant 15 minutes. Parfois, le module ne semble plus réagir aux envois de commande, cette évolution permettra de voir si c'est le module radio qui est bloqué (problème déjà rencontré sur le forum jeelabs/jeelib#92)

pb66 mentioned this issue Jun 3, 2018

Can a delay between canSend returning true and calling sendStart cause problems? #104

Open

sanbee referenced this issue Jul 17, 2019

add John O's trick to sync on an extra AA from the preamble

6f1af25

this change also sends out one more 0xAA preamble byte

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

There's a way to reset the rf module? #92

There's a way to reset the rf module? #92

marcolettieri commented Mar 29, 2016

glynhudson commented Mar 29, 2016

marcolettieri commented Mar 29, 2016

jcw commented Mar 29, 2016

glynhudson commented Mar 29, 2016

marcolettieri commented Mar 29, 2016

JohnOH commented Mar 29, 2016

marcolettieri commented Mar 29, 2016

JohnOH commented Mar 29, 2016

glynhudson commented Mar 29, 2016

JohnOH commented Mar 29, 2016

marcolettieri commented Mar 30, 2016

marcolettieri commented Mar 30, 2016

jcw commented Apr 8, 2016

jcw commented Apr 8, 2016

marcolettieri commented Apr 8, 2016

jcw commented Apr 8, 2016

JohnOH commented Apr 9, 2016

marcolettieri commented Apr 9, 2016

JohnOH commented Apr 9, 2016

glynhudson commented Apr 10, 2016

marcolettieri commented Apr 12, 2016

JohnOH commented Apr 12, 2016

marcolettieri commented Apr 12, 2016

JohnOH commented Apr 12, 2016

glynhudson commented Apr 18, 2016

glynhudson commented Apr 28, 2016

jcw commented Apr 28, 2016

There's a way to reset the rf module? #92

There's a way to reset the rf module? #92

Comments

marcolettieri commented Mar 29, 2016

glynhudson commented Mar 29, 2016

marcolettieri commented Mar 29, 2016

jcw commented Mar 29, 2016

glynhudson commented Mar 29, 2016

marcolettieri commented Mar 29, 2016

JohnOH commented Mar 29, 2016

marcolettieri commented Mar 29, 2016

JohnOH commented Mar 29, 2016

glynhudson commented Mar 29, 2016

JohnOH commented Mar 29, 2016

marcolettieri commented Mar 30, 2016

marcolettieri commented Mar 30, 2016

jcw commented Apr 8, 2016

jcw commented Apr 8, 2016

marcolettieri commented Apr 8, 2016

jcw commented Apr 8, 2016

JohnOH commented Apr 9, 2016

marcolettieri commented Apr 9, 2016

JohnOH commented Apr 9, 2016

glynhudson commented Apr 10, 2016

marcolettieri commented Apr 12, 2016

JohnOH commented Apr 12, 2016

marcolettieri commented Apr 12, 2016

JohnOH commented Apr 12, 2016

glynhudson commented Apr 18, 2016

glynhudson commented Apr 28, 2016

jcw commented Apr 28, 2016