Welcome to the third instalment of Dive Into JeeNodes. Some real hardware now!
Both the remote sending side and the more nearby reeiving side of the wireless sensor link are handled by a JeeNode – which is essentially an Arduino-like microcontroller with some support circuitry, plus a low-power wireless radio module.
The JeeLink is a modified version of a JeeNode in a USB-stick form factor and enclosure.
Remote nodes
But let’s start with that remote JeeNode first. What we’re going to set up is a little self-contained unit with a light sensor, a battery pack to power the whole thing, and the proper software pre-loaded onto the ATmega328 microcontroller inside that JeeNode.
The whole point of this “node” is that it’s completely autonomous. You’ll set it up once, take it to the place where you want to perform the light level measurements, hook up the battery pack, and that’s it. Its only task is to periodically measure the current light intensity, and report it over wireless – so that we can pick up the signal and pass it to the Raspberry Pi in a central location in the house, collect the data, tie it into the web server, and make it available on the local Ethernet network for visualisation in the browser.
Let’s set up that node now – except that it won’t be the final measurement code. Let’s start with a simpler goal first: sending out a counter value once a second, to see if we can pick up that value. With a little blink “blip” to let us know that the node is doing its work. But no light sensor for now…
As it so happens, JeeLib now includes an example sketch which does exactly that – see test1.ino on GitHub for the code (make sure you have the latest version of JeeLib!).
Uploading
To get this code into the JeeNode, we need to communicate with it. This is done by connecting the JeeNode to our workstation / laptop – the one where we installed the Arduino IDE. That connection is created via a USB cable and “BUB”, as follows:
The next step is to tell the IDE which serial port to use to reach our JeeNode:
Go to the “Tools -> Serial Port” menu in the IDE, and select the serial port under which the USB BUB has registered itself. The actual name will depend on the platform (Windows, Mac OSX, or Linux) and in the case of Mac OSX, also on the unique name of that particular USB BUB.
Now, we need to load the proper sketch into the Arduino IDE:
Go to the “File -> Sketchbook -> libraries -> JeeLib -> DIJN -> test1” menu. This will load the test sketch.
To check whether the code is in good shape, click on the leftmost round button with the checkmark in it (or go to the “Sketch => Verify / Compile” menu – same thing).
(rf12_sendNow was recently added to JeeLib, make sure you’re using a recent version)
If all is well, you’ll get one line from the compiler, reporting something like:
Binary sketch size: 3,958 bytes (of a 32,256 byte maximum)
The value may differ a bit, but this indicates that the sketch is ok and can be uploaded.
The last step is where the real upload takes place, and since it includes the compile step, you could in fact have skipped that last instruction above.
Click on the second button from the left (the one with the arrow pointing right).
If all is well, you’ll see some LEDs blink the USB BUB, and when all is done a promising message “Done uploading.” will appear in the IDE (in the middle green bar).
If you get an error, make sure you have selected the proper board type (menu “Tools -> Board -> Arduino Uno”). Still no luck? Check that the USB serial port connection, the cable, the BUB, and the JeeNode are all hooked up as shown above. When in doubt, disconnect and reconnect gently.
Getting through this first upload is an important milestone. There are a few trouble spots, depending on the platform you use. You may have to install the latest FTDI USB driver. You may have to check that the serial USB drivers are present. There is not much generic advice to give here – other than “google for the error message you get”, in the hope that others have run into the same issue and that you’ll find a page with solution or tip.
At this point, you should see a brief LED flash once a second. This indicates that the JeeNode is running the test sketch and sending out its counter packet once a second.
Congratulations, you have set up a live test node for your wireless sensor network!
(This series of posts is also available from the Dive Into JeeNodes page on the Café wiki.)
Your test1 sketch seems to contain some errors: when uploaded, the JeeNode’s LED turns on and remains on rather than flashing. I think there are at least 2 reasons for this: 1. This one is obvious: You should add a delay after led(true). Otherwise (unless the rf12 functions are extremely slow!) led(false) will execute so soon that the “true” state (which, confusingly, is apparently interpreted as “off”) won’t be observable. 2. This one is non-obvious, and I didn’t spend the time to figure it out: Even adding the extra delay, I still saw no flashing until I commented out the guts of the loop, i.e. all lines including some rf12_* function. Why? Your guess is (hopefully) better than mine.
Also, you probably want to tell users to modify the RF12_868MHZ parameter in rf12_initialize as appropriate. And because both the stated intent and overall tone of DIJN indicate that the prior-knowledge threshold is low, you should also probably explain that in order to make such a modification, they’ll need to save test1 as a new sketch, because examples that ship with libraries are read-only.
Speaking of the stated intent and overall tone: I don’t mean to be unfairly critical, and I appreciate you providing this content. But in my view a lot is either left out, scattered around, outdated, or just plan wrong that’s making using JeeNodes in general, and following the DIJN tutorial in particular, much harder than it would seem to need to be. (Coincidentally, I’m diving into JeeNodes just as DIJN is being posted.)
For example, it took me a long time to find any documentation confirming that my “board type” should be Arduino Uno. I realize that this is explained in this very post, and once you know where it is you can also find it in one or more forum posts. But I didn’t start here (in fact this blog posting didn’t exist when I started). And when things weren’t working, it was very non-obvious if I should choose Uno, some other option, or if a JeeNode board type should be showing up that wasn’t. In fact my problem was something else, and you’re quite right that you can’t proactively anticipate and address every installation problem. But it seems like very straightforward and unambiguous hardware documentation of this sort should exist without the extraneous (for people who have prior experience with Arduino or other microcontrollers) content in these blog postings, and without having to search through a bunch of unorganized forum postings (actually two different sets because of the legacy platform). Maybe such documentation exists, but I couldn’t find it, and it’s not for a lack of looking. And it would be especially helpful if the code works as advertised, so when we get unexpected results we can more confidently infer something is wrong on our end.
Another example which I’ll give in order to be helpful to newbies rather than just beating a dead horse: I use the USB-BUB II, and after wrestling with it for awhile, eventually discovered that I needed to install the FTDI USB driver. This is in fact documented on Modern Device’s USB-BUB II product page, and shame on me for not reading more carefully first time around. But it is kind of buried pretty far down on the page. And even then it’s not altogether clear if I needed just the VCP driver, or the D2XX Direct driver as well. The answer, for others who may be having trouble, is just the VCP driver, which can be downloaded here: http://www.ftdichip.com/Drivers/VCP.htm. You say above that “there isn’t much generic advice to give”, but I disagree: the above link contains drivers for all major hardware platforms, and maybe could be part of a standard setup or troubleshooting checklist? Again, the answer is retrospectively obvious and accessible. But when something is going wrong and you don’t know what the problem is, ambiguity increases problem-solving time a great deal.
I realize that Modern Device is a separate entity, so maybe it’s not technically you’re responsibility in that particular case. But I think the two examples I’ve given (and there are lots of others) are both cases in which: (i) newbies may not understand the problem, correct configuration, etc., and figuring it out might be very time-consuming; whereas (ii) you do understand / know, and it should be fairly easy to anticipate the common pitfalls, and extremely easy to document solutions / correct procedures in a format that saves users a great deal of time and frustration.
Hello Ray, I’m sorry to hear that you had so much trouble, and am aware of (at least some of) the problems with the documentation. That was one reason to start the DIJN series, by the way.
The problem with the test1 sketch may be caused by having an older version – the latest one should flash more clearly.
My intention is to start by getting the DIJN content up-to -date, and from there update other docs, wiki pages, and broken/outdated URLs. Note that the wiki is writable (see this post, earlier today).
I had no problems, your instructions were clear and not too verbose, and my Jeenode is happily flashing 1 per sec.
@jcw: thanks for your response. i appreciate how hard it is to both make cool things and to document everything for people with varying skill / knowledge levels, and when technology (yours and 3rd-party) changes so quickly. @len / @jcw: it’s interesting and a little puzzling that test1 works for you when it didn’t for me. jcw mentioned that i might have an older version of the sketch, but the one i’m using is from the JeeLib i downloaded today from GitHub. I’ll post the actual sketch code i’m using below — can either of you verify that i’m in fact using the latest? also, just looking at the code, it seems that it should not in fact flash the LED once per second because of issue #1 i mentioned above: led(true) is followed by led(false) with no explicit delay, just a few lines of code. It is of course possible that those lines of code consume 1 second, but i wouldn’t think so. am i missing / misunderstanding something?
/// @dir test1 /// Simple node-alive check, sends out one test packet per second. const byte LED = 9; byte counter; // turn the on-board LED on or off static void led (bool on) { pinMode(LED, OUTPUT); digitalWrite(LED, on ? 0 : 1); // inverted logic } void setup () { // this is node 1 in net group 100 on the 868 MHz band rf12_initialize(1, RF12_868MHZ, 100); } void loop () { led(true); // standard idiom for waiting until we can send a new packet while (!rf12_canSend()) rf12_recvDone(); // actual packet send: broadcast to all, current counter, 1 byte long rf12_sendStart(0, &counter, 1); rf12_sendWait(1); led(false); // increment the counter (it'll wrap from 255 to 0) ++counter; // let one second pass before sending out another packet delay(1000); }Odd, that is indeed the latest. The rf12_sendWait was added to make the LED flash last a little longer.
Ray, is your RFM12B module actually working (e.g. with RFDemo sketch)?
The instructions are clear and I am using a jeenode usb for remote. Got the avrdude skt500 etc error message when uploading test 1, but turned out that I had selected Arduino uno board, should have been a Duemilova w/Amega etc. Flashing nicely at 1 sec..
Just to clarify for others following this thread – Glyn’s experience depends on the build date of his hardware.
As of mid-Jan 2012, JeeNodes ship with OptiBoot 4.4, which is compatible with Uno boards (the previous bootstrap was for Duemilanove’s)… JeeNode Wiki.
For the very first time, I’m using a JeeNode v6 that I built a bit over a year ago. When I tried uploading the sketch I received an avrdude error `avrdude: stk500_getsync(): not in sync: resp=0x98′. I realized I should not be using the “Uno” Board type, and instead use the Duemilanove with Atmega 328. I also realized the ‘test1’ code is using the wrong radio frequency for me, since I’m in the USA. I actually had to look at my order invoice from Modern Device to determine that I have a 915 Mhz part. Then I could not figure out where the LED is, or which pin on the JeeNode corresponds to pin 9. This post –> https://jeelabs.org/2009/11/06/activity-led/ solved the problem for me.