Porting MySensors to work with the RadioHead library

hek

You only need to initiate the MySensor class with the rfm69 class like this in the gateway (and sensors):

https://github.com/mysensors/Arduino/blob/development/libraries/MySensors/examples/SerialGateway/SerialGateway.ino#L44

MyTransportRF69 radio;

lafleur

I had done that, getting error...

Some questions:

I notice that the MyTransportNRF24 had definition for the pins in the function, RM69, has none...
I take it, its defaulted to the Moteino standards pinout?

The file MyHwATMega328.cpp is for the 328, i assume that I would need to make one for the ATmega1284P chip? if there are any changes needed.

Thanks I will work on these error, if you have any insight on cause, please let me know...

(sure wish the IDE was better.....)

Arduino: 1.6.1 (Mac OS X), Board: "MoteinoMEGA"

SerialGateway.ino:56:26: error: no matching function for call to 'MySensor::MySensor(MyTransportRF69 (&)(), MySigningNone&)'
SerialGateway.ino:56:26: note: candidates are:
In file included from SerialGateway.ino:34:0:
/Users/lafleur/Desktop/MySensor-Arduino-development/libraries/MySensors/MySensor.h:78:2: note: MySensor::MySensor(MyTransport&, MyHw&, MySigning&)
MySensor(MyTransport &radio =*new MyTransportNRF24(), MyHw &hw=*new MyHwDriver()
^
/Users/lafleur/Desktop/MySensor-Arduino-development/libraries/MySensors/MySensor.h:78:2: note: no known conversion for argument 1 from 'MyTransportRF69()' to 'MyTransport&'
/Users/lafleur/Desktop/MySensor-Arduino-development/libraries/MySensors/MySensor.h:69:7: note: MySensor::MySensor(const MySensor&)
class MySensor
^
/Users/lafleur/Desktop/MySensor-Arduino-development/libraries/MySensors/MySensor.h:69:7: note: candidate expects 1 argument, 2 provided
Error compiling.

hek

@lafleur

Yeah, the work on the TransportRF69 need some polishing. It defaults to monteino pins right now. If you have the time add configuration to the driver, please help out.

I don't have any MonteinoMega so I really don't know how it differs regarding hw. Hopefully not too much.

lafleur

I get the same error's if I select the standard Moteino and the RF24 radio???

so, I must have a version skew or IDE issue...

I'm using the source code form the development branch....

Arduino: 1.6.1 (Mac OS X), Board: "Moteino"

SerialGateway.ino:57:26: error: no matching function for call to 'MySensor::MySensor(MyTransportNRF24&, MySigningNone&)'
SerialGateway.ino:57:26: note: candidates are:
In file included from SerialGateway.ino:34:0:
/Users/lafleur/Desktop/MySensor-Arduino-development/libraries/MySensors/MySensor.h:78:2: note: MySensor::MySensor(MyTransport&, MyHw&, MySigning&)
MySensor(MyTransport &radio =*new MyTransportNRF24(), MyHw &hw=*new MyHwDriver()
^
/Users/lafleur/Desktop/MySensor-Arduino-development/libraries/MySensors/MySensor.h:78:2: note: no known conversion for argument 2 from 'MySigningNone' to 'MyHw&'
/Users/lafleur/Desktop/MySensor-Arduino-development/libraries/MySensors/MySensor.h:69:7: note: MySensor::MySensor(const MySensor&)
class MySensor
^
/Users/lafleur/Desktop/MySensor-Arduino-development/libraries/MySensors/MySensor.h:69:7: note: candidate expects 1 argument, 2 provided
Error compiling.

This report would have more information with
"Show verbose output during compilation"
enabled in File > Preferences.

? 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.

Porting MySensors to work with the RadioHead library

6

11.7k

11.2k

113.0k