Skip to main content

You are here

SOLVED: Newbie questions

23 posts / 0 new
Last post
jon bondy
SOLVED: Newbie questions

I have not purchased a JeeNode yet, but I want to. I have used Arduinos for quite a while...

1) if I am careful to turn the transmitter off when I'm not using it (can I turn the transmitter off?), can I run 10 or 20 of these in a room at the same time, without them interfering with each other?

2) where can I find documentation about the board (pin outs, wiring diagram, etc)? Where can I find sample program source code?

3) do I program JeeNodes with the Arduino IDE, or with something else?

4) if I want to communicate with a group of JeeNodes from a single control desktop computer, what hardware do I use to add the wireless capability to the desktop?

5) does the JeeNode RF interfere with WiFi?

6) what do you suggest for enclosures or battery packs for the JeeNode?



Go get some jeenodes, they are great stuff.

1) Yes you can turn the transmitter off, if you don't send anything it will be off. Yes you can run 10-20 off them in the same room, but it will take some programming for them not to disturb one another.

2) All documentation can be found on this website.

3) Yes, you use the Arduino programming environment.

4) I think that is the JeeLink.

5) Nope.

6) that is mostly up to your needs. Cardboard boxes will do for enclosure. Big batteries for long runtime, small for shorter.

jon bondy

Thanks for your help!

Can you explain more about "it will take some programming for them not to disturb one another"? What are the issues? Not having the transmitter on at the wrong time? Having check bytes in messages? Retries?


The official rule (yes, even these small transmitting devices are regulated by law) is that you can't have any sender transmitting more than 1% of the time. This means that, if you have all of the nodes sending at their maximum allowed "duty-cycle" of 1%, you could theoretically have 100 devices before the frequency band was occupied all of the time.

In reality, you nodes would probably be sending less than 1% of the time---most reporting applications send packets every few seconds, and one packets takes only a couple of ms. That means there is more than enough free space (time) on the frequency band. However, it is possible that all of your nodes try to transmit at the same time, so they still "clash".

The RF12 library (in jeelib, the code that comes with JeeNodes) has a function to check that the band is free, so that the node will only send if no other node is sending. If you obey the 1% rule and use this function, the nodes should after a while automatically start their transmissions when the other nodes are silent. It works like this:

byte count=0; void loop(){ count++; while(!rf12_canSend()) rf12_recvDone(); rf12_sendStart(0,&count,sizeof count); delay(2000); }

If you have 20 nodes doing this, they might start all at the same time, but one will be first and start sending---the others will stay in the while-loop until the air is free of transmissions again. Then the second will start, etc. Because they now finish sending after each other, they will be done with the delay() in that same order, with some time between them; and there should be no more clashes!


Hi Padvinder95, I recall a topic on the forum describing that:

The RF12 library (in jeelib, the code that comes with JeeNodes) has a function to check that the band is free, so that the node will only send if no other node is sending.

doesn't actually work yet.


I think this is the post:


Hmm, I had missed that one.

However, there is also the ACK functionality: request an ACK, and if you don't get it, (sleep for some time and) try again. Then you will end up in the same situation, with all the nodes transmitting at different times.

jon bondy

I want to control my JeeNode network from a desktop computer. Is there a device that I can connect to a USB port that will allow me to send and receive radio messages from a desktop computer?


You could have a look in the Jeelabs webshop:

jon bondy

I am aware of JeeLink. From my reading, it appears to be an Ardunio/radio combination that has a USB interface built in. I guess that the desktop computer could communicate with custom software in the Arduino, which in turn sent or received data over the radio link. What would be much simpler/easier would be a radio device that connected to a desktop computer via USB, so that a desktop program could send and receive messages directly over the radio network (rather than needing the JeeLink Arduino to pass the messages back and forth). Does such a device exist?


The RFM12B has very limited buffering and requires real time handling - desktops don't go in for that type of work. I guess there could be other devices that can receive in a manner you describe but they have never been mentioned on this forum. You could use another type of JeeNode - JeeNode USB for instance. You could also use an Arduino with a wireless card.

jon bondy

I read that the RF12Demo program is loaded onto each JeeNode, but I cannot find the source code for that demo anywhere. Would someone please point me there?


@jon, here is the RFM12demo. Generally, if you go to the JeeLabs Shop, individual items have pointers back to full descriptions, build instructions and other resources.

jon bondy

This code turns a light on, emits a beep, and waits for someone to touch an input; it also will time out after 5 seconds. After the "for" loop, I try to send a message back to another node (#26). While that message is being transmitted, the CRC is wrong. Any idea what is wrong with the last 10 lines of code?

// turn light on pinMode(4, OUTPUT); // 4 is port 1 digitalWrite(4, HIGH); // emit tone on speaker pinMode(6, OUTPUT); // 6 is port 3 tone(6, 250, 500); // wait for switch closure for (int i = 0; i < 5000; ++i) { testbuf[0] = i / 256; testbuf[1] = i % 256; // the readCapacitivePin function also causes a 1 ms delay pinMode(5, INPUT); int c; c = readCapacitivePin(5); // port 2 if (c > 1) { digitalWrite(4, LOW); // turn the light off break; } }; digitalWrite(4, LOW); // turn the light off // transmit response dest = 26; // this is desktop computer cmd = 'a'; sendLen = 2; // message stuffed in above loop byte header = cmd == 'a' ? RF12_HDR_ACK : 0; if (dest) header |= RF12_HDR_DST | dest; rf12_sendStart(header, testbuf, sendLen); cmd = 0;
jon bondy

Ah. I needed a rf12_sendWait.


I often find a solution after posting for help - I think it focuses the mind.

jon bondy

I have all four nodes working nicely. When I drive the system from a JeeNode USB and a terminal program, each node (and only that node) reacts when I address it. When I drive the system from a program I wrote (which is writing the same strings), all four nodes react at the same time. It is as if I had broadcast to them all, rather than sending to a specific node. I am performing a "69,2a" command, which should send a one-byte message to node 2. When I do this, nodes 1, 2, 3, and 4 all respond at the same time. The baud rate, data bits, stop bits, and parity seem to be correct. I'm puzzled.

I'm using a single AA battery to power the JeeNodes (using the AA Power Board). If it just sits there, waiting for a transmission, any idea how long the battery will last? I'm running the Demo program with some custom modifications (which would not kick in until a packet is received with the right data)


If you have the JeeNodes waiting for a transmission (receiver on) I don't think you will get much time out of them. Have you seen which describes a smarter listening algorithm.

jon bondy

Thanks, but the transmissions are not periodic.

I still have no idea why the nodes react individually when I control them via Putty, but they react as a group when I control them (using the same strings) using my custom software. Argh.


As hard is it is to come to terms with the two transmissions must be different. Is there anything you can post that people can look over?

jon bondy

I found it. In one case I was sending "69,2a" and in the other I was sending "69,2,a". That additional "," was causing the problems for some reason.




If you're interested in the reason: a comma starts a new part, number, or byte.

It works like this: when the sketch receives a number (0-9), it stores that. If it gets another number, it appends that (so two characters sent over serial, '6' and '9', get stored as the byte/integer value 6, then 69). Now if you send a comma, you indicate you're starting a new number, so the old one (69) is added to the send buffer, and the current number is reset to 0, waiting for more number characters to come in.

If you send not a comma, but an a or an s, you indicate that the last number you sent (2 in your case) is the ID to send to, either with or without (a or s) acknowledgement.

Because you issued a comma after the 2, that 2 got appended to the send buffer (which now held 2 bytes: 69 and 2), then the current value was reset to 0. Issuing an a now uses that 0 as address and sends the buffer with ACK request. Since 0 is the broadcast address, every node responded to this.

Premium Drupal Themes by Adaptivethemes