Help with Multiple plugs on JeeNode

Jee Labs Talk » How can I fix ... ?

Help with Multiple plugs on JeeNode

(19 posts) (2 voices)

Tags:

No tags yet.

hve

Hello,
I have progressed with the JeeNode project to the point where I have two JeeNodes working with the an analog input on port three and reporting back to my computer. I am having difficulty in understanding how to add the Pressure Plug on one of the other ports. I have the pressure plug reporting from a Jn connected to my computer, but cannot figure out how to add the code to the transmitting JN. My ultimate goal is the have 2 pressure plug, an analog value( representing current draw ) and a digital input all on the same JN reporting back to my Home automation computer for appropriate action and monitoring. Is there a tutorial that describes the methods to use available anywhere? Thanks for your help.

Posted 16/04/2010 14:22:33
jcw

You will need to either construct a larger packet containing all the values one after the other, or send out individual packets with a type code. If you're sampling / reporting all values at the same frequency, then the first approach is probably simpler.
See the "newData" code at or some older and simpler code at for examples.
On the receiving end, you then have to separate the individual readings again.
I'd love to generalize this sort of multiplexing / demultiplexing of data streams, because mix-and-match is one of the reasons JeeNode have 4 ports in the first place, but haven't gotten around yet to doing so.

Posted 16/04/2010 15:39:55
hve

Thanks for the reply. I have been looking over these codes, but there is to much I don't know yet. If I could just figure out what you need to do and in what sequence that might help me to figure out how to do it. e.g. setup radio, take measurement, construct packet, send packets. Do you know of some tutorial where I can find this stuff out? Would this be on the Arduino site? Thanks.

Posted 18/04/2010 18:38:09

jcw

I don't know of other places to point to :( - maybe someone else has a suggestion.

How about this:

    struct {
        int pressure1;
        int pressure2;
        int analog;
        int digital;
    } payload;

    // set the fields as needed:
    payload.pressure1 = 123;
    payload.pressure2 = 234;
    payload.analog = 345;
    payload.digital = 1;

rf12easySend(&payload, sizeof payload);

Does that help? It's only the sending half, but you have to start somewhere :)

Posted 18/04/2010 19:52:29

jcw

Does the info in -wirelesslightsensor/> help?

Posted 18/04/2010 19:58:38
hve

Ok, that helps. so I take the readings, put them in the appropriate variable to construct the payload and send it. I am going to try that and see what happens. I did the LDR and that is working even then low power mods. I think the low power mods are making things a little to confusing for me. So I am going to try the code without the low power mod and see if I can get the LDR and the pressure sensor to work. Thanks for your quick response. I read a comment somewhere that "this guy is working all the time". You are proving him right.

Posted 18/04/2010 21:15:29
jcw

Heh, re "working all the time" - it's not work for me ... it's what I love doing :)

Posted 19/04/2010 00:01:07

hve

Hello Jean-Claude,

I have been working on this pressure plug today after some time delay. This is the code I cobbled together:

    //BMP085
    // Ports demo, reads out a BMP085 sensor connected via I2C
    // 2009-02-17  http://opensource.org/licenses/mit-license.php
    // $Id: bmp085demo.pde 4727 2009-12-08 21:39:49Z jcw $

    #include "Ports.h"
    #include "PortsBMP085.h"
    #include  // needed to avoid a linker error :(

    PortI2C two (4);
    MilliTimer readoutTimer, aliveTimer;
    word runningAvg;

    BMP085 psensor (two);

    void setup() {
        Serial.begin(57600);
        Serial.print("\nbmp085demo;
        rf12config();

        rf12easyInit(0);    // set up easy transmissions at maximum rate
           // may omit following call if calculate() won't be called later on
        psensor.getCalibData();
          //uint16t praw= psensor.measure(BMP085::PRES);
          // runningAvgPres =uint16t praw;
    }

    void loop() {
        delay(1000);

        rf12easyPoll();    // keep the easy tranmission mechanism going
         if (readoutTimer.poll(1000)) {
            // keep track of a running 5-second average
            //runningAvgPres = (4  runningAvgPres + psensor.measure(BMP085::PRESS)) / 5;
            uint16t praw= psensor.measure(BMP085::PRES);
            uint16t traw = psensor.measure(BMP085::TEMP);
            int32t pres;  //declare variable
            int16t temp;  //declare variable
            psensor.calculate(temp, pres);    
            byte value=(pres0.00029529983071);  //convert pascals ti inches of HG

            rf12easySend(&value, sizeof value);  // send measurement data, but only when it changes
         }  
            if (aliveTimer.poll(60000))  // force a "sign of life" packet out every 60 seconds
            rf12easySend(0, 0);     
         }

and this is the output:

    ^ i30 g212 @ 915 MHz 
    ? 94 147 239 223 114 48 181 120 92
    ? 191 140 36 17 231 51 31 175 110 162 92 111 7 75 254 23 138 240 29 181 153
    ? 39 159 199 169 67 165 188 182 199 123 181 127 87 135 206 205 23 33 104 110 10
    ? 156 143 203 175 246 48 55 254 140 196 97 31 248 119 253 247 232 56 86 201 186
    ? 183 208 16 85 238 125 183 251 114 159 137 233 47 239 95 206 107 237 221 223 144
    ? 187 4 166 47 56 112 221 159 178 239 213 207 153 7 58 181 166 39 253 204 223
    ? 28 12 95 236 205 115 174 155 115 239 57 246 208 101 242 209 169 219 188 215 247
    ? 43 67 87 223 254 157 157 63 211 254 95 29 35 123 171 140 136 201 121 175 128

I am just trying to get a reading from the plug to the receiver before elaborating to the next step. The set up works withe Ldr, so I surmise that there is something wrong with the code. Can you see anything wrong? Thanks.

Posted 25/04/2010 17:48:23

hve

I just tried to transmit just a constant with out any better out come.

    byte value=  12;

rf12easySend(&value, sizeof value); // send measurement data, but only when it changes

with this output:

    Current configuration:
     ^ i30 g212 @ 915 MHz 
     ? 178 227 6 158 207 238 190 127 213 55 219 119 159 175 252 50 207 122 202 71 123


				Posted 25/04/2010 18:04:08


	
		
			
								
					hve

				
			
			
				
I have done some more diddling and now seem to get valid data with this statement:
       psensor.calculate(temp, pres);    
       float value= (pres0.00029529983071);  //convert pascals ti inches of HG
       rf12easySend(&value, sizeof value);  // send measurement data, but only when it changes
 
and this output:
 ^ i30 g212 @ 915 MHz 
OK 33 205 200 231 65
-> ack
OK 33 158 202 231 65
-> ack
OK 33 44 197 231 65
-> ack
OK 33 92 195 231 65
 -> ack

This should read about 29.53 (inches of Hg)  So what am I not interpreting properly.



				Posted 25/04/2010 18:33:34
			
		
	
	
		
			
								
					jcw

				
			
			
				
Quick note - please indent code in future posts with four spaces. Enclosing them in back-ticks does not quote them properly. I've edited the above posts accordingly :)



				Posted 25/04/2010 22:06:05
			
		
	
	
		
			
								
					hve

				
			
			
				
Ok, more progress.  This is the code that I am using:
    //BMP085
    // Ports demo, reads out a BMP085 sensor connected via I2C
    // 2009-02-17  http://opensource.org/licenses/mit-license.php
    // $Id: bmp085demo.pde 4727 2009-12-08 21:39:49Z jcw $
    #include "Ports.h"
    #include "PortsBMP085.h"
    #include  // needed to avoid a linker error :(
    PortI2C two (4);
    MilliTimer readoutTimer, aliveTimer;
    word runningAvgPres;
    BMP085 psensor (two);
    void setup() {
        Serial.begin(57600);
        Serial.print("\nbmp085demo;
        rf12config();
    
        rf12easyInit(0);    // set up easy transmissions at maximum rate
           // may omit following call if calculate() won't be called later on
        psensor.getCalibData();
        //uint16t praw= psensor.measure(BMP085::PRES);
          runningAvgPres =psensor.measure(BMP085::PRES);
    }
    void loop() {
         delay(1000);
          rf12easyPoll();    // keep the easy tranmission mechanism going
          if (readoutTimer.poll(1000)) {
              float tempF;
              float presHg;
              uint16t traw = psensor.measure(BMP085::TEMP);
              uint16t praw = psensor.measure(BMP085::PRES);
    
        // omit following code to avoid linking in some complex calculation code
           int16t temp;
           int32t pres;
            psensor.calculate(temp, pres);
            tempF=(((temp.9)/5.0)+32.0);    //convert Celcius to Fahrenheit
            presHg=(pres0.00029529983071);  //convert pascals to in of Hg
            presHg=presHg+0.52238540053;    //elevation correction
            float value= presHg;
            rf12easySend(&value, sizeof value);  // send measurement data, but only when it changes
         }  
            if (aliveTimer.poll(60000))  // force a "sign of life" packet out every 60 seconds
            rf12easySend(0, 0);     
         }
 and this is the output I am getting:
    Current configuration: ^ i30 g212 @ 915 MHz 
    OK 33 193 100 142 65
     -> ack
    OK 33 38 100 142 65
     -> ack
    OK 33 146 102 142 65
     -> ack
    OK 33 98 104 142 65
     -> ack
What I need to know is how to interpret the output.  I am sending 29.35 (in Hg) from node 1.  I would like to be able to decipher the output so that I know which node is sending the data, so that I know what data to expect.  Thanks.



				Posted 25/04/2010 22:07:35
			
		
	
	
		
			
								
					jcw

				
			
			
				
Now on to the actual posts...
The "? ..." lines are probably noise, not actual data. Only "OK ..." packets are valid. The fact that you didn't get any OK's means either the transmit node isn;t working or you are out of range (unlikely).
Please remove the "delay(1000)" - a node needs to be responsive to both sensor changes and packets (including acknowledgement packets). This will probably become a FAQ one day, but the general rule is: don't use delay's, use timers and poll them instead.
The OK packets you are seeing is a 4-byte floating point value. Literally, i.e. 4 bytes of data which represent the floating point value. I will be adding more support for generic decoding of such packets in JeeMon, but for now the easier way is probably to stick to ints.
So instead of "float value = ...", use "int value = ..." or "long value = ...". Then the incoming bytes are easier to convert back.
A 2-byte int reply, for example "OK 12 34", can be converted back with this expression: first-byte + 256 x second byte.
I now realize that what is obvious to me is probably confusing for most people (yeah, I'm a bit crazy) ...
The point with "packets" as the RF12 driver deals with them, is that they are binary data, not text. This is not only considerably more efficient (and easier for computers), it's also very different from a common way of "sending" data, over a wire or wireless.
For example, the normal way to send a value to a serial port is to "print" it. Which simply means: convert to text and then send the characters across.
With the RF12 model, you send the raw data across, and then convert it to text later. So the receiving end has to do the "print" so to speak.
I can solve this fairly easily and naturally in JeeMon, but I'm aware of the fact that not everyone will want to use JeeMon. With just a JeeLink reporting "OK blah blah blah" packets, it's not instantly clear how the reported values relate to the original measurement data.
Hmmm... this needs to be worked out and explained with some examples. I'll try do this in upcoming weblog posts - but it'll take me a few days to get there.



				Posted 25/04/2010 22:24:15
			
		
	
	
		
			
								
					hve

				
			
			
				
The value that I am trying to transmit is xx.yy.  I need this .yy because of what I am trying to measure, hence the floating point arithmetic.  i can get around that by multiplying xx.yy by 100 before transmission and then after receiving and conversion I can divide by 100 again.  This still leaves me with the need to decode the "OK blah blah blah".
Ok this is what I am getting from the output:
OK 33 136 11
 -> ack
 ? 6 64 1 151 163 199 234 216 28 61 255 255 255 235 246 253 110 153 29 15 165
OK 33 136 11
 -> ack
 ? 191 233 204 52 126 86 85 159 80 122 207 233 195 126 17 161 54 211 38 85 250
I know that the stuff following the ? is garbage.  So that leaves Ok 33 131 11 converting as per your post and dividing by 100 leave me with 29.52, which is exactly correct.  Awesome.
Now on to building a payload structure as per your previous suggestion.  How so I know which bytes of the transmission go with the payload parts?



				Posted 26/04/2010 13:49:14
			
		
	
	
		
			
								
					jcw

				
			
			
				
Using  as example, you have 4 ints in a struct, they will arrive as "OK 33" and then 8 bytes. First two are pressure1, next tow pressure 2, etc.
FYI, the first byte contains the ID of the sender, but you have to extract it using modulo-32 arithmetic: "int id = byte % 32;" in C.
I hope this gets you going. Now I've got to figure out how to best support and document this stuff - and simplify it, preferably.



				Posted 26/04/2010 14:43:07
			
		
	
	
		
			
								
					hve

				
			
			
				
OK, thanks.  Got the node thing working.  The two bytes per variable I can work with also.  However that brings up another problem.  I used floating point before because I needed the resolution.  With the two byte limitation i would get "  136 11" or "136 10" or "136 12".  This would convert to 29.52, 26.96 and32.08, which would be way to course.  I need at least a .5 resolution.  Could I just send the raw data and then convert at the receiver?  The raw data is probably a integer in the range of 100,000.  Would that be doable?
Thanks.



				Posted 26/04/2010 15:37:12
			
		
	
	
		
			
								
					jcw

				
			
			
				
You've got some leeway left with the range. Multiply by 500, send, divide by 500 at the receiver? Gives 5x higher res.
Or go for longs, 4 bytes each, result = b1 + 256  (b2 + 256  (b3 + 256  b4)).
Even floats can be done, but they probably aren't needed here.



				Posted 26/04/2010 15:46:24
			
		
	
	
		
			
								
					hve

				
			
			
				
OK thanks.  I will try both and see how they work.
Going with the long value gives me OK 33 136 11 0 0. So that does not seem to help. However multiplying by 5 and then dividing by 5 seems to be better.  That give me a resolution of .5, still would like a little better resolution like .1 or so.



				Posted 26/04/2010 16:29:35
			
		
	
	
		
			
								
					jcw

				
			
			
				
Hey, that's not fair - you're changing your requirements! Use the long, multiply by 10000.



				Posted 26/04/2010 17:01:52