Odd thing in roomNode.pde « Jee Labs Talk

Odd thing in roomNode.pde

(18 posts) (4 voices)

Tags:

No tags yet.

bmj
I have updated one of my Nodes to: "$Id: roomNode.pde 6348 2010-12-05 16:15:16Z jcw $" from the "Examples -> RF12 -> roomNode " and flashed the JeeLink whit the latest RF12demo. I note two odd things: If the PIR is trigged 5 transmissions is made (as if the ACK is not received) If the PIR is left alone for many minutes the PIR bit is still set to one (trigged).
```
    OK 35 167 73 195 0
     -> ack
    OK 35 167 73 195 0
     -> ack
    OK 35 167 73 195 0
     -> ack
    OK 35 167 73 195 0
     -> ack
    OK 35 167 73 195 0
     -> ack
    .......
    OK 3 166 73 195 0
```
OK 35 58 73 199 0 -> ack OK 35 58 73 199 0 -> ack OK 35 58 73 199 0 -> ack OK 35 58 73 199 0 -> ack OK 35 58 73 199 0 -> ack ..... OK 3 57 73 199 0
This (http://talk.jeelabs.net/topic/727#post-4147) topic is set to solved but there is no info about how it was done? And only address part of the problem. Does any one know more about this. Do I need to upgrade to some newer ZIP:s?
I just noticed something else odd. The light values is inverse of what it was before. The formula used before know indicates 100% in total darkness (before it indicated 100% in bright sunlight).
All nodes running the old firmware behaves normal.
Posted 14/02/2011 12:31:50
outtasight
Hi bmj,
In my second post in that thread I describe what I did to remedy the problem, and it is still working like this now.
```
    I opted to change the if-statement in WaitForAck in roomNode.pde to follow
    RF12ACKREPLY by changing: rf12hdr == (RF12HDRDST | RF12HDRACK | myNodeID))
    into rf12hdr == (RF12HDRDST | RF12HDRCTL | myNodeID))
```
Your second problem with the PIR bit has just popped up here too when I was trying to show PIR activity from remote room nodes with LED's. They switch on right away and never go off again, and in the received packets the PIR is always on.
I have been glancing over JCW's code, but had no time yet to fully dive into it. Maybe tomorrow....
Posted 15/02/2011 00:42:28
bmj

Hi Outtasight
Aha... I understand I'll try it right away. Thank you for your explanation.
Jean-Claude if you read this maybe you should update roomNode.pde and the ZIP:s?
I'll try to find time to read the code and search for the PIR problem.
It is easy to change the code on the PC to function with the inverse light values but backward compatibility is always a god thing :-)

Posted 15/02/2011 07:39:24
outtasight
Hello bmj,
I found something out about our common PIR observations. First I have to note that I have the ELV PIR sensor on my roomnode board, so beware if you have one of the others.
The ELV has an open collector output, so when activated it pulls the pin on the Atmega to ground, and the pin reads 0 in the program. The poll() function in the PIR class seems to assume the PIR reads 1 when activated, which the ELV doesn't do. So I flipped the value of the PIR pin like this:
```
    change:  byte pin = digiRead();
    into : byte pin = 1-digiRead();
```
and all the logic started to work again, including the fallback to 0 after 30 seconds.
If you want to use this for surveillance, or really need to know the status of your remote PIR's for some other reason, there is more to this story. Let me know if you need that info too. Real tired now...
Posted 16/02/2011 22:26:32
bmj

Hello Outtasight,
Excellent! Late last night I also noted that inverting the value from the ELV seemed to work. But went to bed without a explanation to way it worked. A 'solution' without a explanation is not a god one and I intended to work more on it on Sunday so you have saved me a lot of head-scratching.
If it is not to time consuming for you to writ down the extra information you have discovered I'm curious to know it and it can be critical for some one else who reads this.

Posted 17/02/2011 08:33:22
outtasight

Hi bmj,
I recognize that. Same 'problem' over here! :-)
JC's code was made to detect movement in such a way that the RF12 is not franticly sending every PIR change state out to the other nodes. Therefore the PIR has to be silent for al least 30 seconds (PIRHOLDINGTIME) before another PIR packet can be sent out. If there is movement within this 30 seconds, the timer gets reset to 30 again. Any packet you might receive from this node during this state has moved=1 .
As long there is movement all is ok, but the problem arises when movement stops. As there are no more interrupts generated, you have to wait up to 5 minutes for the roomnode to send out its regular-service-interval packet again, in which moved=0. This is caused by that 30 second delay timing from above, which doesn't generate an interrupt when it reaches zero, so no packet gets sent when that happens.
So, JC's code serves it's intended purpose very well, but surveillance needs a different approach... Maybe you want to scratch your head over that one, Sunday? :-)
Ron.

Posted 17/02/2011 22:36:14
bmj
Hello Outtasight,
First of all, have you noticed something odd when you set the line "#define SERIAL 1" to 0 (zero)? My node stops transmitting! I'm uncertain if this has some thing to with the line:
```
    delay(2); // make sure tx buf is empty before going back to sleep
```
not executing any longer or some thing else. I will investigate further.
Regarding the PIR not transmitting "movement stopped" is it that bad? My commercial alarm-system reacts on the first move and emits sound and turn on the exterior lights for 5 minutes. If no further move is detected it silences. This is exactly implemented by JC's code. You may vary the on time by decreasing the interval for "normal package" (at cost of energy).
If you really need a independent "off-package" one solution is to use JC's scheduler and set it to transmit an extra "normal package" a set time X after a motion (eg. 30s or 1s) IF a new motion are detected during that time reset the scheduler to X.
Posted 18/02/2011 12:57:08
outtasight

Hi bmj,
I changed SERIAL to 0 but found no problems receiving data from the node. Odd indeed...
Surely it's not bad for its intended purpose, but I need other behaviour. I want to create a dynamical overview of the house so I need it all to be as accurate as possible.
I indeed changed the packet sending rate for now to get my off-packet quicker, but indeed at the cost of energy, so this will not do. I going to rework the code to better suit my signalling needs and sending packets to a minimum. It has to wait for a while because I want to have the receiving end and display of my 'overview system' done first. Sawing, drilling, sanding, band aids... :-)

Posted 19/02/2011 21:18:48

bmj

I think I have found the trouble:

    void setup () {
    #if SERIAL || DEBUG
        Serial.begin(57600);
        Serial.print("\nroomNode.3;
        myNodeID = rf12config();
    #else
        rf12initialize(myNodeID, RF12868MHZ, 5);
    #endif

should maybe look like

    void setup () {
    #if SERIAL || DEBUG
        Serial.begin(57600);
        Serial.print("\nroomNode.3;
    #endif

    myNodeID = rf12config();

Other wise the netgroup is always set to 5 and nodeid set to 2.

More information is available her:

http://jeelabs.net/projects/cafe/wiki/Rf12initialize%28%29 http://jeelabs.net/projects/cafe/wiki/Rf12config%28%29

Posted 25/02/2011 07:53:19

jcw

Ouch. Good catch! The reason I commented out the rf12config() call, is that it does report info on the serial port. I'll make a change to disable the serial port reporting when given an argument.

Posted 25/02/2011 14:53:06
jcw

> I'll make a change to disable the serial port reporting when given an argument.
Done. In latest RF12 code. See also .

Posted 25/02/2011 15:14:47
bmj

Excellent! And its god to have you back! When you find time for it implement Outtasights solutions in this topic. They solve the rest off the problems in roomNodes.pde I have the new patched version running on 5 nodes now and as far as I know there are no bugs left to solve.

Posted 26/02/2011 08:13:51
jcw

I'm adding the ACK -> CTL fix. W.r.t. PIR polarity - which type of PIR do you have? Green board (ELV) or blue board?

Posted 26/02/2011 14:18:46
bmj

I have the ELV.

Posted 26/02/2011 15:09:51
jcw

Ok, I've also added a PIRFLIP option. See

Posted 26/02/2011 16:11:22
bauhaus53

I have updated the JeeLink with the new RF12demo and a JeeNode/RoomBoard with the "roomNode.pde 7201 2011-02-26 16:10:57Z jcw"
Monitoring ... ... from JeeNode-Monitor: ROOM 203 1 44 241 0 ... from JeeLink-Monitor: OK 5 203 88 241 0
why is in the JeeLink "double" humidity an no Motion-Flag?
A Motion "changes" the Node-ID (?) on the JeeLink-Monitor from 5 to 37 (OK 37 203 88 241 0). Is this correct?
Thanks for the support

Posted 27/02/2011 16:31:03
jcw

You're looking at a raw packet of bytes, unlike the ROOM message.
88 / 2 = 44 = humiity
88 % 2 = 0 = motion
The motion report is sent with a request for an ack, which adds 32 to the header byte. The node ID is moduo 32, i.e. "37 % 32".

Posted 27/02/2011 23:48:21
bauhaus53

@ Jean-Claude: Thank you - and sorry for the silly question (a simple look to line 700 - 703 from the RF12Demo.pde ... )

Posted 28/02/2011 17:20:22