Interrupt on recieve radio data

[dzairo]

hmmm.. why you want use irq ?
save battery ? irq not solve this problem..
of course irq can wake up mcu (save some power) but radio us still on then not save too much ..
for example CC1101 have this special function WOR register .. radio itself wake up and listening .. and go sleep if no preamble and address ...
there is possible do this ..
set longer period between packet if not received ack . and in another side wake up radio and listening twice this period .. then go sleep..
if set max transmit to 15 and period set around 100ms then total time is 1.5sec ..

this is my idea..

[axillent]

@dzairo said:

save battery ? irq not solve this problem..

that is a correct point
for NRF24 to raise interrupt you need to keep it in radio listening
If I'm remembering right NRF24 is consuming about 12mA while listening

[dzairo]

yes... this is not good point how to save battery ..
if you want then .. need wake up radio very predefined time .. and listening ..
but then MCU also have power consumption .. then not good point ..

but using MySensors .. new features for controller ..
buffer for packet ..
node every 1 sec wake up and ask for new command .. if not then return sleep .. if yes then process ..
gateway .. will hold new packet in special buffer .. if receive request from node then send this packet .. if not then still hold or after predefined time flush packet.

MySensors have very big potencial . to make very good sensor network..

[axillent]

it is more question of device design
what kind of device we are talking about?

sensors usually are working in active mode by sending data on certain predefined events (for example shift in temperature or elapsed time)
they will sleep between events and will be not able to receive
time to time (not often, for example battery powered zwave devices are initiating pooling each 30 minutes by default) the device can send a request to controller for a parameters updates and will wait for the reply before going sleep

if your battery device need by design be always accessible in passive mode (passive means the connection is initiated by third party) it probably means that design is wrong and can be optimized

if you still need this way you probably can use push-pull idea most modern gadgets are using (like iphone). This way your device is connecting to the server on a regular basis to ask very short questions "is anything awaiting for me?". Shorter payload - less time for the transmit, less power needed
but do not expect the device to work for a long time

[jonnyfishman]

Hi guys, thanks, for the replies and ideas.

'axillent', your quite right. I realised this morning that of course I can send a request to the controller for the current values when the user presses the button to turn on the RFID module. This way I can leave the sensor in the sleep setting until it is actually needed.

Presumably this is as simple as sending the command:

gw.request(CHILD_ID, V_VAR1); - copied from 'EnergyMeterPulseSensor'

One thing I'm not sure about is whether the following function is called by gw.request or does it get called from somewhere else (I can't test it at the moment to find out)?

void incomingMessage(const MyMessage &message) {
if (message.type==V_VAR1) {
state = message.getLong();
Serial.print("Received state from gw:");
Serial.println(state);
}
}

[hek]

Yes, the request-response will be delivered to your callback function.

[jonnyfishman]

Hi Hek,

Thanks for the response. I've set the following (full code is attached but is still quite messy RFID.ino ):

gw.begin(incomingMessage);
gw.request(CHILD_ID_TEMP, V_TEMP); 

and

// Manage incoming messages from Gateway 
void incomingMessage(const MyMessage &message) {
Serial.println("incoming");
 // We only expect one type of message from controller. But we better check anyway.
     if (message.type==V_TEMP) {    
// Change relay state
if (lockStatus != message.getBool() )
setLockState(message.getBool(), false); 

// Write some debug info
Serial.print("Incoming lock status from GW:");
Serial.println(message.getBool());
} 
}//end incomingMessage

I'm using Pidome and can see the response being sent back to the node as:

05-12-2014 20:10:46: 0;0;3;0;9;send: 0-0-2-2 s=1,c=1,t=0,pt=0,l=4,st=fail:19.1
05-12-2014 20:10:45: 0;0;3;0;9;read: 2-2-0 s=1,c=2,t=0,pt=0,l=0:
05-12-2014 20:09:28: 0;0;3;0;9;send: 0-0-2-2 s=1,c=1,t=0,pt=0,l=4,st=fail:19.1
05-12-2014 20:09:27: 0;0;3;0;9;read: 2-2-0 s=1,c=2,t=0,pt=0,l=0:

But in terminal I never see the response (no incoming message displayed). Is there a problem with st failing or is it something wrong with the server response?

Thanks,
Jon

[hek]

Looks like you don't get any ack from the sensor. So it could very well be com problems.

[jonnyfishman]

Hi Hek,

Solved the ack problem, just moved the sensor closer to the GW. I'm now getting a response but its not consistent.

 //Setup completed
 RF24 initialized and GW contacted
 //GW present from other sensors
 Battery Voltage: send: 2-2-0-0 s=3,c=1,t=38,pt=7,l=5,st=ok:0.1
 Temperature: send: 2-2-0-0 s=1,c=1,t=0,pt=7,l=5,st=ok:24.7
 
 //Triggering the button sends gw.request, the following is output 
 send: 2-2-0-0 s=2,c=2,t=36,pt=0,l=3,st=ok:1.4
 
 //Triggering the button again gets this response
 read: 0-0-2 s=2,c=1,t=36,pt=0,l=1:0
 Incoming Radio
 Alarm Disabled
 Incoming lock status from GW:0
 send: 2-2-0-0 s=2,c=2,t=36,pt=0,l=1,st=ok:0
 
 //Triggering again
 read: 0-0-2 s=2,c=1,t=36,pt=0,l=1:0
 Incoming Radio
 Alarm Disabled
 Incoming lock status from GW:0
 send: 2-2-0-0 s=2,c=2,t=36,pt=0,l=1,st=ok:0

I don't understand why the first one always fails, would it be better to trigger the callback manually to pick up a response?
Also is it possible to introduce a wait or while loop to prevent the rest of the loop being processed until the GW replies?

Thanks,
Jon

[hek]

@jonnyfishman said:

would it be better to trigger the callback manually to pick up a response?

No that won't help (as long as you call gw.process() ).