Porting MySensors to work with the RadioHead library

? Offline

@lafleur:
I got the same error, also 1.6.1 (Mac OSX) board Uno, and Nano. My solution was to remove the signing object in the initialization:

// Construct MySensors library
MySensor gw(radio);

Then it compiles without issues. I have other issues though, but they might be related to the radios.

lafleur

removing the Construct object, will cause other error, as the gw is not defined at this point...

SerialGateway.ino: In function 'void setup()':
SerialGateway.ino:67:3: error: 'gw' was not declared in this scope
SerialGateway.ino: In function 'void loop()':
SerialGateway.ino:85:3: error: 'gw' was not declared in this scope

I'm new to Arduino and this IDE, so it painful trying to work my way into this code...

kolaf

Hi guys,

I lost some of my inspiration when I couldn't get the RF69 implementation to be stable for more than a few days and TOSA said he could before he disappeared without telling me how :-(. However, Easter is upon us and I thought I would give it another try.

I updated to the latest version of the development branch, and things seem to have changed a bit since I was here last time. Is there anything that needs to be updated on the RF69 side? At the very least it seems to be missing a definition for IS_RF69HW, as well as probably some useful defaults.

kolaf

I also note that there now is an include for a specific radio in the serial Gateway example. This is different from the way it was earlier where the radio type was defined in MyConfig. Wasn't this a better solution?

Anyway, is it sufficient simply to change the included radio and then expect the serial Gateway code to work correctly on a moteino?

hek

@kolaf

The defines in MyConfig started to become a big mess. Especially if we would want to have a Moteino variant of the gateways downloadable using codebender.

Ok, just updated gateway classes to include the available options like this:

// NRFRF24L01 radio driver (set low transmit power by default) 
MyTransportNRF24 transport(RF24_CE_PIN, RF24_CS_PIN, RF24_PA_LEVEL_GW);  
//MyTransportRF69 transport;

// 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)
MySensor gw(transport, hw /*, signer*/);

So you should only have to enable the one you want to use. Do the same in the sensor/actuator sketch (haven't updated all of them yet).

dzairo

.. and hardware distance test? rfm69hw have +20dB .. pls make test in building .. or make compare test with nRF24L01+ ..
we waiting for this ..
best regards..

hek

@dzairo said:

we waiting for this

I'm waiting also. Please do the test @dzairo!

dzairo

sorry .. is possible make test with this module if you have it ?
I can compare only nrf24l01+ with cc1101 868mhz ..
in free area is possible with standard nrf24l01+ with good antenna from wifi get 200m .. pcb antenna give less then 30m . rfm69hw is good because is possible set lowe transfer speed less then in nrf24l01+ ..
if make test with CC1101 868mhz version with +14dB output power then no problem get distance in my house 3 floor ..

best regards

? Offline

@lafleur:
I only removed the "signer" out of the initialization and changed the line to the code above. I did not comment the whole line.

@kolaf:
To make the library work for the RFM69HW for me, I needed to change the radio pointer to an object amongst other things.., which combination did eventually do the trick, I do not know for sure.
I will summarize the changes I did to get connection between two nodes using the RFM69HWs.

The problem I had was that the radio would not start up for me. It was stuck at the RFM69.cpp initialization at:

do writeReg(REG_SYNCVALUE1, 0xAA); while (readReg(REG_SYNCVALUE1) != 0xAA);
do writeReg(REG_SYNCVALUE1, 0x55); while (readReg(REG_SYNCVALUE1) != 0x55);

So the changes I did were:

In MyTransportRF69.h:

@@ -37,7 +37,7 @@ public:
        uint8_t receive(void* data);
        void powerDown();
 private:
-       RFM69 *radio;
+       RFM69 radio;
        uint8_t _address;
 };

and in MyTransportRF69.cpp:

 MyTransportRF69::MyTransportRF69()
        :
        MyTransport(),
-       radio()
+       radio(10,2,true,0)  //I set the Pins manually (SPI SS 10, InterruptPin 2, IsHW = true, and InternalInterrupt 0)
 {
 }
 void MyTransportRF69::init() {
        // Start up the radio library
-    radio->initialize(FREQUENCY,_address,NETWORKID);
+    radio.initialize(FREQUENCY,2,NETWORKID); //I changed the node_ids manually for each node, see below for comment
+    radio.rcCalibration();
+    Serial.println("Radio init done");
 #ifdef IS_RFM69HW
-    radio->setHighPower(); //uncomment only for RFM69HW!
+    radio.setHighPower(); //uncomment only for RFM69HW!
 #endif
-    // radio->encrypt(ENCRYPTKEY);
+    radio.setPowerLevel(20); //I decreased the powerlevel a bit, since I had some troubles transmitting between two nodes on my desk before when using the full power.

of course change all the following "radio->" to "radio." with string replace.

Also I realized that the NODEID is not set properly using the _address argument, I had a serial println there and it always returned "0 (zero)", which should not be correct. So I set them manually for each node.
I also copied the latest version of Felix LowPowerRFM library into utils from here:
https://github.com/LowPowerLab/RFM69
(I do not know if they differ much, the diff is not very conclusive due to different formatting)

I am using an Arduino Buono UNO clone set with a switch to run at 3.3V with the RFM69HW connected via breadboard. With the changes above, all was compiled and started up.

But I had a major problem with the Dev branch that in general that no ACKs at all were send or at least received, even when using the NRF2401+. So that is why I did not continue with the RFM69HW at the moment. The master branch on the very same setup (using the standard radio) did work without any troubles.

I managed to get connection between the nodes (e.g. in the serial output of the gateway the request for parent was received, but all messages had a "failed" status). I last checked the dev-branch last week.
I am away over Easter, but am willing to try a bit more afterwards, if I get the Dev branch running in general with ACKs...

I got inspired by this project:
http://www.instructables.com/id/Uber-Home-Automation-w-Arduino-Pi/?ALLSTEPS
There is also a forum here:
http://homeautomation.proboards.com/board/2/openhab-rfm69-based-arduino
but eventually I turned here, since mysensors seems to have more active support and a already a bigger community and codebase. However there they have a RFM69 gateway running with nodes. So it might be worth to check it out how they did it (that is also how I got the RFM69 running in the first place).

Sorry for the long post..

Cheers!

hek

@daenny

Thanks for the analysis. The RFM69 code really need a loving hand after being almost untouched for months since ToSa disappeared. There shouldn't be any changes done to the LowPowerLab code (but it hasn't been updated either).

The question is if hardware acks i coming in but is just picked up wrongly from LowPowerLab-library?

I should really setup a test rig with those radios... But my time is limited.. If you're interested in helping out finding the root cause for the RFM69 ack-problems I would be super grateful.

The ack-problems you're seeing on NRF24L01 will investigate by me.

kolaf

@daenny I've started playing with it now, and the first fix for your pointer problem is to initialise the radio pointer correctly which is not done in the current implementation. I simply added the following line to the beginning of init:

radio=new RFM69();

No further changes were then necessary to the pointers.

kolaf

I have two devices talking to each other, but I'm a bit rusty, so can't immediately see what's happening from the output. This is the sensor side:

req id
send: 3-3-0-0 s=255,c=3,t=3,pt=0,l=0,sg=0,st=fail:
send: 3-3-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,st=fail:1.4.1
send: 3-3-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=fail:0
sensor started, id=3, parent=0, distance=1
send: 3-3-0-0 s=255,c=3,t=11,pt=0,l=12,sg=0,st=fail:Power sensor
send: 3-3-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=fail:1.0
send: 3-3-0-0 s=1,c=0,t=13,pt=0,l=5,sg=0,st=fail:1.4.1
send: 3-3-0-0 s=2,c=0,t=6,pt=0,l=5,sg=0,st=fail:1.4.1
find parent
send: 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc:

And this is the gateway side:

0;0;3;0;9;gateway started, id=255, parent=0, distance=1
0;0;3;0;14;Gateway startup complete.
0;0;3;0;9;read: 3-3-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
3;255;3;0;7;
0;0;3;0;9;read: 3-3-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
3;255;3;0;7;
0;0;3;0;9;read: 3-3-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
3;255;3;0;7;

Can anyone tell me what is happening here? I'm using a sensor I configured a long time ago, so it is already received its ID from the gateway previously.

kolaf

Okay, I have done some digging.

The gist of my last post was that it received no response for any of the messages sent directly to the Gateway, they never even arrived at the gateway. The only message that arrived was the broadcast message.

The first hints for me was the initialisation string from the gateway. It indicates that it is initialised with the address 255. This is a bit weird, since the Gateway source code provides a value of 0 to gw.begin(). Looking into the source for this it turns out that the value provided here is never stored in the node configuration, and thus is never used as the address for the node. I made some changes to store the address in the node configuration, and suddenly the Gateway started to respond to the messages from the sensor.

As for the acknowledgements, it turns out that ACKRequested never seems to return true even if we use sendWithRetries. If we assume this to be true and transmit acknowledgements regardless (which is correct since we always use send with retries) the status of all the send messages from the sensor revert to "ok".

I guess that this fixed to the acknowledgements issue is good enough for now, but I am definitely not sure about the issues with the Gateway node id. Any thoughts on this would be very welcome.

diff --git a/libraries/MySensors/MySensor.cpp b/libraries/MySensors/MySensor.cpp
index 91644e0..d5badb3 100755
--- a/libraries/MySensors/MySensor.cpp
+++ b/libraries/MySensors/MySensor.cpp
@@ -142,6 +142,13 @@ void MySensor::begin(void (*_msgCallback)(const MyMessage &), uint8_t _nodeId, b
 			// Try to fetch node-id from gateway
 			requestNodeId();
 		}
+	} else {
+				if (_nodeId != AUTO) {
+			// Set static id
+			nc.nodeId = _nodeId;
+			// Save static id in eeprom
+			hw_writeConfig(EEPROM_NODE_ID_ADDRESS, _nodeId);
+			}
 	}
 
 	setupNode();
diff --git a/libraries/MySensors/MyTransportRF69.cpp b/libraries/MySensors/MyTransportRF69.cpp
index b55ce14..3874773 100644
--- a/libraries/MySensors/MyTransportRF69.cpp
+++ b/libraries/MySensors/MyTransportRF69.cpp
@@ -29,7 +29,7 @@ uint8_t MyTransportRF69::getAddress() {
 
 bool MyTransportRF69::send(uint8_t to, const void* data, uint8_t len) {
 	// Make sure radio has powered up
-	return radio->sendWithRetry(to,data,len);
+	return radio->sendWithRetry(to,data,len,5,200);
 }
 
 bool MyTransportRF69::available(uint8_t *to) {
@@ -45,9 +45,13 @@ uint8_t MyTransportRF69::receive(void* data) {
 		// data[i]= (void)radio->DATA[i];
 	// }
 	memcpy(data,(const void *)radio->DATA, radio->DATALEN);
-	if (radio->ACKRequested())
+	if (radio->ACKRequested() || 1)
     {
+      Serial.println("Acknowledgement requested");
       radio->sendACK();
+      Serial.println("Sent acknowledgement");
+    } else {
+    	Serial.println("Not wanting acknowledgement");
     }
 	return radio->DATALEN;
 }

hek

@kolaf

Thanks! I will have a look at the id=0 problem tonight.

? Offline

@kolaf
Nice work, I am new completely new to the MySensors code, so I could not dig into it deep enough to see how everything is build up.
I completely overlooked that the pointer is not initialized properly, but your fix is definitively easier :).

@hek
My guess is that the problem with the ACKs and Gateway ID could be the same for the nrf radio, which might explain the troubles I had with the dev branch?

kolaf

@hek
Great. In the meantime I'm doing some stability testing of the current code base.

hek

@kolaf

:thumbsup:

hek

Ok, tried to clean up some of the mess in RFM69 (and gw node id).

I have a hard time to do any verification tonight here (the family sleeping too near the "lab room"). Would be great to get some feedback if you have your gears setup and ready for tests.

reddy11

@hek
Thank you for taking a look at the RFM69 code. I downloaded the development branch. While I was able to get it to compile, it does not seem to work, but Im note sure if it is something I am doing.
Background:
I had the RFM69 radio working with code from the development branch I downloaded in early Jan. I have a few sensors that and a serial gateway using the Jan code.

After downloading the latest development branch I tried to update my serial gateway, assuming it would still be able to read the sensors with the older code.

Observations:
Currently I cannot see any of the older nodes that I have. I have not tried to update any of the nodes yet, so I don't know if my problem is with the current code or not.
Currently there is not a myconfig.h option to set the RFM69HW option

I have been stumbing around the code trying to get a feel for it, and I am not and expert but am wondering if Line 137 of Mysensor.h has anything to do with the problem?

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

Should there be something that would define MyTransportRFM69 instead?

Thoughts?

Would love to get this working and ultimately figure out the MQTT server options.

Thanks!

hek

Yes, it differs a bit. You can now initialise the transport using RFM69 like this (see constructor default values in https://github.com/mysensors/Arduino/blob/development/libraries/MySensors/MyTransportRFM69.h.
5:th argument is the one you're looking for. I Might add a default for this in MyConfig as well if this is something people change often.

#include <MyTransportRFM69.h>
#include <MySensor.h>

MyTransportRFM69 transport(freqBand, networkId,  slaveSelectPin, interruptPin, isRFM69HW, interruptNum);

MySensors gw(transport);

Porting MySensors to work with the RadioHead library

18

11.7k

11.2k

113.0k