What radio to use? NRF24L01+, RFM69, RFM73 ?


  • Hero Member

    The RFM73 and RFM75 appear to be nRF24L01+ derivatives (not identical but very similar); still in the 2.4GHz band but with a little more power so they might have better range.

    The RFM69* is a completely different family - operating at either 433MHz or 868/915MHz (same chip, different passives), and with a lower speed, narrower bandwidth - and very different electronics (both the analog/RF and the digital registers). It should have much longer range, because of the power, the limited speed, and the lower frequencies (which penetrate better).

    I am still interested in the nRF family because I've invested in it, and it's used here anyway for other things (higher bandwidth applications). But if one was ONLY going to build MySensor nodes, the RFM69 family could be very attractive because range is probably more important than bandwidth for our purposes here.



  • Ok range is definitely a priority. But if you compare the long range version of NRF24L01+ and the RFM69, does RFM69 still offer advantages in range (penetration of walls) and power consumption in sleep and send ?

    Also does the differnent Mhz versions of the RMF69 differ in range or penetration ?

    And how do you connect the RMF69 to the arduinos? In every build-sketch I have seen here on the mysensors build-page there is a link to how to connect the radio NRF24L01+. but no info of how to connect the RFM69.

    Does the sketches also have to be modified to use the RFM69 radio?


  • Hero Member

    @Cliff-Karlsson said:

    But if you compare the long range version of NRF24L01+ and the RFM69, does RFM69 still offer advantages in range (penetration of walls) and power consumption in sleep and send ?

    I have some of the long range NRF24L01+, and, to be frank, was very disappointed. Perhaps YMMV.but I've given up on it.

    Also does the differnent Mhz versions of the RMF69 differ in range or penetration ?

    Perhaps theoretically, but it's largely academic: if you live in the US you probably want the 915Mhz version for regulatory reasons, whereas I get the impression Europe may be just the opposite.

    And how do you connect the RMF69 to the arduinos? In every build-sketch I have seen here on the mysensors build-page there is a link to how to connect the radio.

    I'ver only ever seen it done one way.



  • One more question after reading a litte more on the RFM69. The RFM69HW offer great range but draws alot of power so I guess I would not be ideal to use in battery powered sensors witch transmits every 60 sec or so.

    But If I use a RFM69HW just in the controller and then use the ordinary RFM69 in the sensors I guess that even large houses with alot of walls would be covered?

    Or am I wrong thinking that if the controler is using a strong radio all the sensor nodes will connect fine even with a very weak radio?



  • A lot of questions now, but is there a ny description of how to connect the RFM69 to an arduino and also what has to be modified in the existing sketches here on mysensors.org to use the RFM69 ?

    Also do I have to do anything special to the controller (rpi+nano) to have it use the RFM69?


  • Hardware Contributor

    @Cliff-Karlsson I could be wrong but it's my understanding that those numbers are for transmit power so I don't think it hurts anything to have an HW in the gateway but I don't think it helps particularly. My guess is that most of these things have more to do with antenna design and orientation than anything. My plan is to have my gateway have the best antenna and orientation I can since it's stashed away in a closet. The sensors (which will be visible) will use smaller antennas and since their orientation is determined more by their location, they are at a disadvantage. So in that case a higher power gateway might allow them to receive information more easily while the better antenna in the gateway allows it to pick up weak sensors more reliably. That's my theory anyway...


  • Hero Member

    Originally I purchased the HW version, because I thought I could just scale back to whatever power level I wanted. However, since then I've learned that the PA needs to be turned on for it to work at all, so now I'm not sure what the actual power range might be, but I'd guess it's higher than for the ordinary W version.

    I should think it would make sense to have your gateway use the HW version, just in case in the future any of the sensors are distant and also require the HW version.

    At the end of the day, it will always depend\ on what you want to do. Some people claim to be perfectly happy with the NRF24L01+, which can also be cheaper, depending on where you buy it. It may turn out to be the sort of thing you need to buy and try in order to really know whether it fits you or not.



  • @NeverDie said:

    make sense to have your gateway use the HW version, just in case in the future any of the sensors are distant and also require the HW version.

    At the end of the day, it will always depend\ on what you want to do. Some people claim to b

    Ok, I am trying to find out what the different versions mean. Does the RFM69-RFM69HC-RFM69HW series just differ in range and possible power-consumption? Where RFM69 has the shortest range and the HW have the longest range?

    Also I have not found any info of how to connect the RFM radio to the arduino, are there any more info on that part?



  • @Cliff-Karlsson I think that :

    • H version stands for High power.
    • C version is pin compatible with RFM12.

    RFM69 uses SPI so the connections are :

    Arduino RFM69
    10 <-------------------> NSS
    11 <-------------------> MOSI
    12 <-------------------> MISO
    13 <-------------------> SCK
    DI00 <-------------------> 2
    GND <-------------------> GND
    3.3V
    ANA : antenna

    NSS, MOSI and SCK are inputs so you need to adapt level if you use 5V arduino


  • Hero Member

    That's right. There are really just two types of RFM69x: the regular kind like the RFM69W, and the high powered kind like the RFM69HW. The other variants are just variations in pinout so as to retrofit to the pinouts of older generation RF chips. If you're starting from a blank page, those won't matter to you.



  • @fets said:

    s so you need to adapt level

    I just got my rfm69hw´s and connected it to an arduino nano for a couple of seconds before i realized that I needed to adapt the level. Is it possible that it survived this mistake?

    I have nov connected a IIC I2C Interface Level Conversion Module 5-3v
    I connected NSS,Mosi,SCK and GND to the "B" side and connected the arduino nano to the "A" side. Is this correct?



  • @Cliff-Karlsson seems correct.
    Personnaly I use 3 * 2 resistors (10k and 4.7k) for NS, MOSI and SCK rfm69hw inputs.
    Don't forget to change MyTransportRF69 contructor to use high power RFM69 😉



  • @fets said:

    H version stands for High power.
    C version is pin compatible with RFM12.
    RFM69 uses SPI so the connections are :

    Arduino RFM69
    10 <-------------------> NSS
    11 <-------------------> MOSI
    12 <-------------------> MISO
    13 <-------------------> SCK
    DI00 <-------------------> 2
    GND <-------------------> GND
    3.3V
    ANA : antenna

    NSS, MOSI and SCK are inputs so you need to adapt level if you use 5V arduino

    I have connected a RFM69HW to my arduino nano+rpi gateway and have connected a RFM69W+Mini Pro 3.3V to a soil sensor but nothing shows up in Domoticz. Do I have to do anything else? Do I need a external antenna? The two RFM's is only like 1m apart.



  • Do I need to alter the code for the gateway or the sensor-sketches?



  • @Cliff-Karlsson said:
    Do I need a external antenna? The two RFM's is only like 1m apart.

    I never tested without antenna. I used simple wire the length dependinf of your frequency?
    Did you look at your arduino serial outpout ?
    If there is nothing, it may that because RFM69 init failed


  • Hero Member

    Yes you should put an antenna on. It doesn't have a PCB trace antenna. A simple piece of wire, typically cut to 1/4 wavelength, will work fine.



  • Ok, I have some thin insulated copper wire, will that work? And how long wire will I need for the 868mhz frequency?

    But just to be clear, do I need to alter the gateway or the sensor sketches in some way to have it use the rfm radio?



  • 1/4 wavelength = (3 10^8 / (868 10^6)) / 4 =>about 8.64 cm



  • Thanks, sorry for repeating the question but do I need to alter the code on gateway or sensors?



  • You only need to create a MyTransportRFM69 instead of MyTransportNRF24. This is the constructor : MyTransportRFM69 (RFM69_FREQUENCY, RFM69_NETWORKID, RF69_SPI_CS, RF69_IRQ_PIN, isRFM69HW, RF69_IRQ_NUM);
    if you use a RFM99H, you have to set the 5th parameter (isRFMHW) to true.



  • Sorry for being semi-retarded, but is this done in the gateway sketch? Sensor
    -sketch or both? Is there any documentation on this part as I am a complete beginner.



  • both, here is the documentation



  • @Cliff-Karlsson You have to change the following setting in Myconfig.h for you radio

    
    /**********************************
    *  RFM69 Driver Defaults
    ***********************************/
    // Default network id. Use the same for all nodes that will talk to each other
    #define RFM69_NETWORKID     100
    
    // Default frequency to use. This must match the hardware version of the RFM69 radio (uncomment one):
     #define RFM69_FREQUENCY   RF69_433MHZ
    //#define RFM69_FREQUENCY   RF69_868MHZ
    //#define FREQUENCY     RF69_915MHZ
    
    // Enable this for encryption of packets
    //#define RFM69_ENABLE_ENCRYPTION
    #define RFM69_ENCRYPTKEY  "sampleEncryptKey"
    
    

    Then in MySensor.h you change the following:

    ifndef MySensor_h
    #define MySensor_h
    #include "Version.h"   // Auto generated by bot
    #include "MyConfig.h"
    #include "MyHw.h"
    #include "MyTransport.h"
    //#include "MyTransportNRF24.h"
    #include "MyTransportRFM69.h" 
    #include "MyParser.h"
    #ifdef MY_SIGNING_FEATURE
    #include "MySigning.h"
    #include "MySigningNone.h"
    #endif
    #include "MyMessage.h"
    #ifdef MY_OTA_FIRMWARE_FEATURE
    #include "utility/SPIFlash.h"
    #endif
    #include <stddef.h>
    #include <stdarg.h>```
    
    
    // look for this lines and changes this
    
    class MySensor
    {
      public:
    	/**
    	* Constructor
    	*
    	* Creates a new instance of Sensor class.
    	*
    	*/
    	//MySensor(MyTransport &radio =*new MyTransportNRF24(), MyHw &hw=*new MyHwDriver()
    	MySensor(MyTransport &radio =*new MyTransportRFM69(), MyHw &hw=*new MyHwDriver()


  • @fets said:

    MyTransportRFM69 (RFM69_FREQUENCY, RFM69_NETWORKID, RF69_SPI_CS, RF69_IRQ_PIN, isRFM69HW, RF69_IRQ_NUM);

    Hmm. I can't get it to work. This is what I have done:
    In Myconfig.H:

    Everything was already set up like the example only 868Mhz was uncommented and that is the same as I got.

    Mysensors.h:

    Commented #include "MyTransportNRF24.h" as in the example.
    Added "#include "MyTransportRFM69.h" as it was not present.

    Under class Mysensor,
    Commented "MySensor(MyTransport &radio =*new MyTransportNRF24(), MyHw &hw=*new MyHwDriver()"
    Added "MySensor(MyTransport &radio =*new MyTransportRFM69(), MyHw &hw=*new MyHwDriver()"

    In the Serial Gateway sketch:
    Commented the line "#include <MyTransportNRF24.h>"
    Commented the line "MyTransportNRF24 transport(RF24_CE_PIN, RF24_CS_PIN, RF24_PA_LEVEL_GW);"
    Added the line "MyTransportRFM69 (RFM69_FREQUENCY, RFM69_NETWORKID, RF69_SPI_CS, RF69_IRQ_PIN, isRFM69HW=true, RF69_IRQ_NUM);

    When trying to upload to my nano I get an error:

    'transport' was not declared in this scope.
    And this line is highlighted: MySensor gw(transport, hw /, signer/);



  • @Cliff-Karlsson, sorry for my late answer.
    you made a mistake on the line added in the serialgateway, it should be :
    MyTransportRFM69 transport (RFM69_FREQUENCY, RFM69_NETWORKID, RF69_SPI_CS, RF69_IRQ_PIN, true, RF69_IRQ_NUM) ;


  • Hardware Contributor

    Has anyone used the Raspberry Pi Gateway implementation with an Rf69? Does it work? On which pin does one connect the interrupt pin ?



  • @fets said:

    Personnaly I use 3 * 2 resistors (10k and 4.7k) for NS, MOSI and SCK rfm69hw inputs.

    Ok, I am continuing with my neverending story 🙂 I have gotten the sketches to complie and I have used a 8.6cm wire as antenna for both of them. But I still does not se any sensors in domoticz. I might have destroyed my radios as I might have accidently used 5 volts on them for a short while. I am trying to use some new radios this time.

    First question: I have a RFM69HW on my gateway and a RFM69W on my sensor (both 868Mhz) They are compatible as I understand only that the H is more powerful?

    Second question: If I am using a Nano I can just cut a cable in two and solder a 10k and a 4.7k in series in between them before connecting the NS, MOSI and SCK ? When checking online voltage divider calculators online and specify 5V in and 10k + 4,7k resistors it says that voltage out is 1.599v


  • Hero Member

    First question: I have a RFM69HW on my gateway and a RFM69W on my sensor (both 868Mhz) They are compatible as I understand only that the H is more powerful?

    Assuming they are of the same frequency, then basically yes, though there is one small difference in the code to account for the RFM69HW having a PA, which MUST be turned on for it to transmit.



  • @Cliff-Karlsson,
    question 2 : I think you misplaced the connection to RFM69 :
    Here is how to connect arduino and RFM69.
    Is it what you did ? (I bet you switched 4.7k ans 10k )

    divisor.png



  • I am still having some problems with getting any data from the RFM69.

    Do I need to define some pins to like in the NRF24L01 section in the Myconfig.h ?
    I have not defined any pins anywhere for the RFM69 or do I not need to do that?

    /**********************************
    *  NRF24L01 Driver Defaults
    ***********************************/
    #define RF24_CE_PIN		   9
    #define RF24_CS_PIN		   10
    #define RF24_PA_LEVEL 	   RF24_PA_MAX
    #define RF24_PA_LEVEL_GW   RF24_PA_LOW
    // RF channel for the sensor net, 0-127
    #define RF24_CHANNEL	   76
    //RF24_250KBPS for 250kbs, RF24_1MBPS for 1Mbps, or RF24_2MBPS for 2Mbps
    #define RF24_DATARATE 	   RF24_250KBPS
    // This is also act as base value for sensor nodeId addresses. Change this (or channel) if you have more than one sensor network.
    #define RF24_BASE_RADIO_ID ((uint64_t)0xA8A8E1FC00LL)
    
    // Enable SOFTSPI for NRF24L01 when using the W5100 Ethernet module
    //#define SOFTSPI
    #ifdef SOFTSPI
    	// Define the soft SPI pins used for NRF radio
    	const uint8_t SOFT_SPI_MISO_PIN = 16;
        const uint8_t SOFT_SPI_MOSI_PIN = 15;
        const uint8_t SOFT_SPI_SCK_PIN = 14;
    #endif
    
    
    /**********************************
    *  RFM69 Driver Defaults
    ***********************************/
    // Default network id. Use the same for all nodes that will talk to each other
    #define RFM69_NETWORKID     100
    
    // Default frequency to use. This must match the hardware version of the RFM69 radio (uncomment one):
    // #define RFM69_FREQUENCY   RF69_433MHZ
    #define RFM69_FREQUENCY   RF69_868MHZ
    //#define FREQUENCY     RF69_915MHZ
    
    // Enable this for encryption of packets
    //#define RFM69_ENABLE_ENCRYPTION
    #define RFM69_ENCRYPTKEY    "sampleEncryptKey" //exactly the same 16 characters/bytes on all nodes!```


  • I even sent a mail to hek asking for help and he said that the only thing I needed to do was to add the line:

    MyTransportRFM69 transport;

    in the serial gateway sketch and "construct your mysensor class with" : MySensor gw(transport);

    I added those two lines in the serial gateway sketch and it complied and uploaded ok but as usual it does not work for me. Can someone give me the exact sketch for a serial gateway using the RFM69W radio and the dallas temperature sketch that is provided on the mysensors-build page modified for use with RFM69W? I would be forever grateful 🙂



  • Still trying, can anyone tell me if this is correct: Nano-Levelshifter-RFM69W

    Untitled.png


  • Admin

    Shouldn't D2-> DI00 have level shifting as well?


  • Hardware Contributor

    @hek said:

    Shouldn't D2-> DI00 have level shifting as well?

    That's IRQ so it should be an output from the radio to the arduino just like MISO right? I was under the impression that radio->arduino links didn't need to be shifted since they're digital connections and the arduino will read 3.3V as HIGH. I could be mistaken of course...

    @Cliff-Karlsson I'm going to start my RFM69 radio testing this weekend (finally) using ProMini 5V <-> level shifter <-> RFM69W so hopefully I can report back with something that works.

    Anytime you have trouble, you should start w/ the simplest case and build up to a real case. So:

    1. use a serial gateway. start it up w/ debug output and make sure that the radio initializes properly.
    2. use the MockMySensors sketch or take a simple sketch and modify it to send an increasing counter value (1,2,3...) every second. start that w/ debug print as well (run 2 arduino ide's so you can use 2 serial monitor windows). That will tell you if the radios are receiving each other properly. You can use this to test range as well my moving one of the radios to another location.
    3. create a simple arduino sketch that reads the sensor. it shouldn't have any mysensors code in it. just report the sensor values to the serial connection. make sure that works. This validates the sensor reading and wiring code.
    4. combine 2+3 so you're sending real data to the gateway == success!


  • Well I am not very experienced so even the trivial task of creating a simple sketch would prove a challenge for me :).

    But this is the SerialGateway sketch I am using:

    #define NO_PORTB_PINCHANGES  
    
    #include <MySigningNone.h>
    #include <MyTransportRFM69.h>
    //#include <MyTransportNRF24.h>
    #include <MyHwATMega328.h>
    #include <MySigningAtsha204Soft.h>
    #include <MySigningAtsha204.h>
    
    #include <SPI.h>  
    #include <MyParserSerial.h>  
    #include <MySensor.h>  
    #include <stdarg.h>
    #include <PinChangeInt.h>
    #include "GatewayUtil.h"
    
    #define INCLUSION_MODE_TIME 1 // Number of minutes inclusion mode is enabled
    #define INCLUSION_MODE_PIN  3 // Digital pin used for inclusion mode button
    #define RADIO_ERROR_LED_PIN 4  // Error led pin
    #define RADIO_RX_LED_PIN    6  // Receive led pin
    #define RADIO_TX_LED_PIN    5  // the PCB, on board LED
    
    // NRFRF24L01 radio driver (set low transmit power by default) 
    //MyTransportNRF24 transport(RF24_CE_PIN, RF24_CS_PIN, RF24_PA_LEVEL_GW);
    //MyTransportRFM69 transport;
    MyTransportRFM69 transport(RFM69_FREQUENCY, RFM69_NETWORKID, RF69_SPI_CS, RF69_IRQ_PIN, false, RF69_IRQ_NUM);
    
    // Message signing driver (signer needed if MY_SIGNING_FEATURE is turned on in MyConfig.h)
    //MySigningNone signer;
    //MySigningAtsha204Soft signer;
    //MySigningAtsha204 signer;
    
    // Hardware profile 
    MyHwATMega328 hw;
    
    // Construct MySensors library (signer needed if MY_SIGNING_FEATURE is turned on in MyConfig.h)
    // To use LEDs blinking, uncomment WITH_LEDS_BLINKING in MyConfig.h
    #ifdef WITH_LEDS_BLINKING
    MySensor gw(transport, hw /*, signer*/, RADIO_RX_LED_PIN, RADIO_TX_LED_PIN, RADIO_ERROR_LED_PIN);
    #else
    MySensor gw(transport, hw /*, signer*/);
    #endif
    
    char inputString[MAX_RECEIVE_LENGTH] = "";    // A string to hold incoming commands from serial/ethernet interface
    int inputPos = 0;
    boolean commandComplete = false;  // whether the string is complete
    
    void parseAndSend(char *commandBuffer);
    
    void output(const char *fmt, ... ) {
       va_list args;
       va_start (args, fmt );
       vsnprintf_P(serialBuffer, MAX_SEND_LENGTH, fmt, args);
       va_end (args);
       Serial.print(serialBuffer);
    }
    
      
    void setup()  
    { 
      gw.begin(incomingMessage, 0, true, 0);
    
      setupGateway(INCLUSION_MODE_PIN, INCLUSION_MODE_TIME, output);
    
      // Add interrupt for inclusion button to pin
      PCintPort::attachInterrupt(pinInclusion, startInclusionInterrupt, RISING);
    
    
      // Send startup log message on serial
      serial(PSTR("0;0;%d;0;%d;Gateway startup complete.\n"),  C_INTERNAL, I_GATEWAY_READY);
    }
    
    void loop()  
    { 
      gw.process();
    
      checkButtonTriggeredInclusion();
      checkInclusionFinished();
      
      if (commandComplete) {
        // A command wass issued from serial interface
        // We will now try to send it to the actuator
        parseAndSend(gw, inputString);
        commandComplete = false;  
        inputPos = 0;
      }
    }
    
    
    /*
      SerialEvent occurs whenever a new data comes in the
     hardware serial RX.  This routine is run between each
     time loop() runs, so using delay inside loop can delay
     response.  Multiple bytes of data may be available.
     */
    void serialEvent() {
      while (Serial.available()) {
        // get the new byte:
        char inChar = (char)Serial.read(); 
        // if the incoming character is a newline, set a flag
        // so the main loop can do something about it:
        if (inputPos<MAX_RECEIVE_LENGTH-1 && !commandComplete) { 
          if (inChar == '\n') {
            inputString[inputPos] = 0;
            commandComplete = true;
          } else {
            // add it to the inputString:
            inputString[inputPos] = inChar;
            inputPos++;
          }
        } else {
           // Incoming message too long. Throw away 
            inputPos = 0;
        }
      }
    }
    
    
    
    

    Does it look alright? I am fairly sure that I also tried using MyTransportRFM69 transport;
    instead of MyTransportRFM69 transport(RFM69_FREQUENCY, RFM69_NETWORKID, RF69_SPI_CS, RF69_IRQ_PIN, false, RF69_IRQ_NUM);
    In the serial monitor only this shows:

    0;0;3;0;9;gateway started, id=0, parent=0, distance=0
    0;0;3;0;14;Gateway startup complete.


  • Admin

    Yes, it looks right.



  • @Cliff-Karlsson First time I used RFM69 I didn't adapt level and the RFM69 initialization couldn't complete : meaning I didn't have the message "Gateway startup complete"
    As soon as I used I used resistors to adapt levels, the initialization was fully completed.
    So I think that your connections are good.
    I think (from memory) that I created MyTransporRFM69 almost the same way as your (I use RFM69HW) :
    MyTransportRFM69 transport(RFM69_FREQUENCY, RFM69_NETWORKID, RF69_SPI_CS, RF69_IRQ_PIN, true, RF69_IRQ_NUM);

    What about your node sketch ? Do you do the same ?


  • Hero Member

    I would wonder whether running some signals through the level shifter and some not might cause the signals to arrive out of phase? Anyway, something to consider if you can't get it to work.



  • Ok, this is my temp sensor sketch. Does it also look Ok?

    /**
     * The MySensors Arduino library handles the wireless radio link and protocol
     * between your home built sensors/actuators and HA controller of choice.
     * The sensors forms a self healing radio network with optional repeaters. Each
     * repeater and gateway builds a routing tables in EEPROM which keeps track of the
     * network topology allowing messages to be routed to nodes.
     *
     * Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
     * Copyright (C) 2013-2015 Sensnology AB
     * Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors
     *
     * Documentation: http://www.mysensors.org
     * Support Forum: http://forum.mysensors.org
     *
     * This program is free software; you can redistribute it and/or
     * modify it under the terms of the GNU General Public License
     * version 2 as published by the Free Software Foundation.
     *
     *******************************
     *
     * DESCRIPTION
     *
     * Example sketch showing how to send in DS1820B OneWire temperature readings back to the controller
     * http://www.mysensors.org/build/temp
     */
    
    #include <MySensor.h>  
    #include <SPI.h>
    #include <DallasTemperature.h>
    #include <OneWire.h>
    #include <MyTransportRFM69.h>
    #define COMPARE_TEMP 1 // Send temperature only if changed? 1 = Yes 0 = No
    
    #define ONE_WIRE_BUS 3 // Pin where dallase sensor is connected 
    #define MAX_ATTACHED_DS18B20 16
    unsigned long SLEEP_TIME = 30000; // Sleep time between reads (in milliseconds)
    OneWire oneWire(ONE_WIRE_BUS); // Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs)
    DallasTemperature sensors(&oneWire); // Pass the oneWire reference to Dallas Temperature. 
    MyTransportRFM69 transport; 
    MySensor gw(transport);
    float lastTemperature[MAX_ATTACHED_DS18B20];
    int numSensors=0;
    boolean receivedConfig = false;
    boolean metric = true; 
    // Initialize temperature message
    MyMessage msg(0,V_TEMP);
    void setup()  
    { 
      // Startup up the OneWire library
      sensors.begin();
      // requestTemperatures() will not block current thread
      sensors.setWaitForConversion(false);
    
      // Startup and initialize MySensors library. Set callback for incoming messages. 
      gw.begin();
    
      // Send the sketch version information to the gateway and Controller
      gw.sendSketchInfo("Temperature Sensor", "1.1");
    
      // Fetch the number of attached temperature sensors  
      numSensors = sensors.getDeviceCount();
    
      // Present all sensors to controller
      for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {   
         gw.present(i, S_TEMP);
      }
    }
    
    
    void loop()     
    {     
      // Process incoming messages (like config from server)
      gw.process(); 
    
      // Fetch temperatures from Dallas sensors
      sensors.requestTemperatures();
    
      // query conversion time and sleep until conversion completed
      int16_t conversionTime = sensors.millisToWaitForConversion(sensors.getResolution());
      // sleep() call can be replaced by wait() call if node need to process incoming messages (or if node is repeater)
      gw.sleep(conversionTime);
    
      // Read temperatures and send them to controller 
      for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {
     
        // Fetch and round temperature to one decimal
        float temperature = static_cast<float>(static_cast<int>((gw.getConfig().isMetric?sensors.getTempCByIndex(i):sensors.getTempFByIndex(i)) * 10.)) / 10.;
     
        // Only send data if temperature has changed and no error
        #if COMPARE_TEMP == 1
        if (lastTemperature[i] != temperature && temperature != -127.00 && temperature != 85.00) {
        #else
        if (temperature != -127.00 && temperature != 85.00) {
        #endif
     
          // Send in the new temperature
          gw.send(msg.setSensor(i).set(temperature,1));
          // Save new temperatures for next compare
          lastTemperature[i]=temperature;
        }
      }
      gw.sleep(SLEEP_TIME);
    }```

  • Hardware Contributor

    Well I'm having problems too... 😧 I'm running basically the same serial gateway code you are and, like you, it starts up fine. For my sensor, I'm using the MockSensor sketch modified to send a counter. That starts up fine as well but can't communicate with the gateway. I tried level shifting IRQ and not level shifting IRQ - no change. Basically the gateway never gets the transmitted message. I'm using a small helical antenna that came w/ the radio on the sensor and a home made dipole on the gateway. I'm going to try and replace my home made antenna with a helical model on the gateway and see what happens.

    Here's what I see on the sensor:

    find parent
    send: 254-254-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc:
    

    I'm using this level shifter. If my antenna mod doesn't work (I'm not expecting it to), I'll try changing this to a resistor network to do the shifting and see if that helps.



  • Hmm...

    I just connected both gateway and temp sensor to the same computer and used the serial monitor and now it shows temp info

    0;0;3;0;9;gateway started, id=0, parent=0, distance=0
    0;0;3;0;14;Gateway startup complete.
    0;0;3;0;9;read: 1-1-0 s=255,c=0,t=17,pt=0,l=3,sg=0:1.5
    1;255;0;0;17;1.5
    0;0;3;0;9;read: 1-1-0 s=255,c=3,t=6,pt=1,l=1,sg=0:0
    1;255;3;0;6;0
    0;0;3;0;9;read: 1-1-0 s=255,c=3,t=11,pt=0,l=18,sg=0:Temperature Senso
    1;255;3;0;11;Temperature Sensor
    0;0;3;0;9;read: 1-1-0 s=255,c=3,t=12,pt=0,l=3,sg=0:1.1
    1;255;3;0;12;1.1
    0;0;3;0;9;read: 1-1-0 s=0,c=0,t=6,pt=0,l=0,sg=0:
    1;0;0;0;6;
    0;0;3;0;9;read: 1-1-0 s=0,c=1,t=0,pt=7,l=5,sg=0:24.5
    1;0;1;0;0;24.5
    0;0;3;0;9;read: 1-1-0 s=0,c=1,t=0,pt=7,l=5,sg=0:24.7
    1;0;1;0;0;24.7
    0;0;3;0;9;read: 1-1-0 s=0,c=1,t=0,pt=7,l=5,sg=0:24.8
    1;0;1;0;0;24.8
    

    I don´t know if it is a range problem or if it is my controller platform.
    I am using a raspberry pi and domoticz and I get a lot of errors like:

    2015-09-28 19:30:16.415 MySensors: Using serial port: /dev/ttyUSB0
    2015-09-28 19:30:17.881 MySensors: Gateway Ready...
    2015-09-28 19:30:36.661 Hardware Monitor: Fetching data (System sensors)
    2015-09-28 19:31:06.795 Hardware Monitor: Fetching data (System sensors)
    2015-09-28 19:31:36.930 Hardware Monitor: Fetching data (System sensors)
    2015-09-28 19:32:07.060 Hardware Monitor: Fetching data (System sensors)
    2015-09-28 19:32:37.168 Hardware Monitor: Fetching data (System sensors)
    2015-09-28 19:33:07.298 Hardware Monitor: Fetching data (System sensors)
    2015-09-28 19:33:37.410 Hardware Monitor: Fetching data (System sensors)
    2015-09-28 19:34:07.541 Hardware Monitor: Fetching data (System sensors)
    2015-09-28 19:34:37.658 Hardware Monitor: Fetching data (System sensors)
    2015-09-28 19:35:07.784 Hardware Monitor: Fetching data (System sensors)
    2015-09-28 19:35:37.925 Hardware Monitor: Fetching data (System sensors)
    2015-09-28 19:36:08.054 Hardware Monitor: Fetching data (System sensors)
    2015-09-28 19:36:38.167 Hardware Monitor: Fetching data (System sensors)
    2015-09-28 19:37:08.298 Hardware Monitor: Fetching data (System sensors)
    2015-09-28 19:37:38.428 Hardware Monitor: Fetching data (System sensors)
    2015-09-28 19:38:08.537 Hardware Monitor: Fetching data (System sensors)
    2015-09-28 19:38:38.666 Hardware Monitor: Fetching data (System sensors)
    2015-09-28 19:38:38.852 Error: Serial Port closed!... Error: End of file
    2015-09-28 19:38:39.513 MySensors: retrying in 30 seconds...
    2015-09-28 19:39:08.518 MySensors: Using serial port: /dev/ttyUSB0
    2015-09-28 19:39:08.518 Error: MySensors: Error opening serial port!
    2015-09-28 19:39:08.799 Hardware Monitor: Fetching data (System sensors)
    2015-09-28 19:39:09.518 MySensors: retrying in 30 seconds...
    2015-09-28 19:39:38.523 MySensors: Using serial port: /dev/ttyUSB0
    2015-09-28 19:39:38.523 Error: MySensors: Error opening serial port!
    2015-09-28 19:39:38.898 Hardware Monitor: Fetching data (System sensors)
    2015-09-28 19:39:39.523 MySensors: retrying in 30 seconds...
    2015-09-28 19:40:08.528 MySensors: Using serial port: /dev/ttyUSB0
    2015-09-28 19:40:08.528 Error: MySensors: Error opening serial port!
    2015-09-28 19:40:09.013 Hardware Monitor: Fetching data (System sensors)
    2015-09-28 19:40:09.529 MySensors: retrying in 30 seconds...
    2015-09-28 19:40:38.533 MySensors: Using serial port: /dev/ttyUSB0
    2015-09-28 19:40:38.534 Error: MySensors: Error opening serial port!
    2015-09-28 19:40:39.107 Hardware Monitor: Fetching data (System sensors)
    2015-09-28 19:40:39.534 MySensors: retrying in 30 seconds...
    2015-09-28 19:41:08.538 MySensors: Using serial port: /dev/ttyUSB0
    2015-09-28 19:41:08.539 Error: MySensors: Error opening serial port!
    2015-09-28 19:41:09.222 Hardware Monitor: Fetching data (System sensors)
    2015-09-28 19:41:09.539 MySensors: retrying in 30 seconds...
    2015-09-28 19:41:38.543 MySensors: Using serial port: /dev/ttyUSB0
    2015-09-28 19:41:38.544 Error: MySensors: Error opening serial port!
    2015-09-28 19:41:39.335 Hardware Monitor: Fetching data (System sensors)
    2015-09-28 19:41:39.544 MySensors: retrying in 30 seconds...
    

    I have tried using two different raspberry pi´s and tried both the stable and the beta of domoticz and I get the same errors everytime.
    I was thinking there was some error in the gateway-sketch/temp-sketch or that the usb-port of the pi could not provide enough power for the nano+RFM69W.



  • @Cliff-Karlsson glad it works now.
    You should now try to use a different power source for node and see if it's stil working. Next start to move your node.
    Regarding domoticz outputs, these are not errors but' just logs from raspberry motherboard sensors.


  • Hardware Contributor

    Well - the good news is that mine is working now. The ??? news is that I'm not sure why. I was using an Uno as my gateway (w/ a dipole antenna) and a 5V mini (small helical antenna) as the sensor and couldn't get anything to go between them. To simply things, I changed the Uno to a 3V mini w/ a monopole antenna and got some traffic, but not very consistent. So I shut everything down, ate some dinner, watched some TV and came back to it. Turned both nodes on and everything was working fine. I rigged up a battery and booster to the 5V mini and started moving it around the house and it's working perfectly. Basically there doesn't seem to be anywhere on my property that I can't get a signal.

    The 5V mini is using a level shifter on all the lines (including IRQ) except MISO so I'll try removing the IRQ shifting next to make sure it works without that. And I need to see if I can get the Uno working as the gateway.

    My best guess is that I had a loose connection in the breadboard (i.e. maybe I should stop buying cheap breadboards). Or maybe start using wire wrap for my prototypes.


  • Hero Member

    @TD22057 said:

    I rigged up a battery and booster to the 5V mini and started moving it around the house and it's working perfectly. Basically there doesn't seem to be anywhere on my property that I can't get a signal.

    Great!



  • So does the RFMxx need level shifters? I was under impression they were like that NRF24LO1+ and could just be wired direct to the minis.



  • @shabba levels shifters needed, unless with pro mini 3.3v



  • Hi I had my RFM69(H)W Gateway and sensors working after several days of trial and error. A couple of days ago I started fiddeling around with the gateways when trying to add a NRF radio. The nrf works great but now my RFM69 has stopped working.

    Can anyone write down a complete step by step instruction of how to get the Serial gateway and sensors working using the RFM69.

    This is what I have done:

    MyConfig.h - Checked that the right radio options was selected.

    Mysensor.h - Added

    #include "MyTransportRFM69.h"

    //MySensor(MyTransport &radio =*new MyTransportNRF24(), MyHw &hw=*new MyHwDriver()
    MySensor(MyTransport &radio =*new MyTransportRFM69(), MyHw &hw=*new MyHwDriver()

    SerialGateway:
    added:
    "MyTransportRFM69 transport (RFM69_FREQUENCY, RFM69_NETWORKID, RF69_SPI_CS, RF69_IRQ_PIN, true, RF69_IRQ_NUM) ;" (I have the H version on the gateway)

    Are there any more steps? anything more I need to add to the SerialGateway Sketch?
    The Sensor-sketches also seems to have been modified recently, how do I add the Radio info in the sketches?



  • Did anyone manage to get direct raspberry pi to RFM69 working? About to roll out a rfm69 network beside my nrf24 one.



  • hi, is there something like the nRF24LE1 (which has an nRF24L01 and 8051 microprocessor in one chip) in the RFM family? thanks!


  • Mod

    @mahesh2000 please don't post the same question in multiple places. It wastes people's time when some details are available in one thread and some details in another thread.
    To anyone responding to @mahesh2000's question, please reply in https://forum.mysensors.org/post/85838 instead.


Log in to reply
 

Suggested Topics

  • 87
  • 3
  • 10
  • 7
  • 8
  • 6

56
Online

11.4k
Users

11.1k
Topics

112.6k
Posts