Wednesday May 19, 2010

New Sun SPOT pricing

David already beat me to the announcement, but here's the scoop.

We are running low on Sun SPOTs... in fact we are sold out in much of the world. We are working feverishly to get our inventory back up, but that isn't the news today. Stay tuned for more on that later.

The real news is only relevant for those in the US today because there are still a few Sun SPOT kits available in our US store. However, this new pricing (modulo currency exchange rates etc) will affect everyone. We are announcing a single price for both retail and educational purchases. This should be of particular interest to hobbyists who, until now, have had to pay full retail price for Sun SPOTs. Now full retail price is just $399.00 for the complete Sun SPOT Java Development Kit (this used to be $750). The kit includes three devices (a base station and two "free-range" Sun SPOT devices) as well as software, documentation and a few accessories.


Sun SPOT Dev kit now $399 for everyone!

Head over to the store and grab one now. This is a great chance to take advantage of the new price on the existing kits. I'm pretty sure that this inventory will run out before we get our new build in, so if you are looking to get a kit in the near future, now is the time.

Tuesday Mar 30, 2010

Summer Research Assistants 2010

Hi everyone,

We are looking for a few summer intern research assistants to help us on the Sun SPOT project. Follow this link: then enter one of the numbers below in the Keyword search for these job openings:
These are student positions just for the summer months (these are NOT permanent jobs). We don't expect these openings to be available for long, so apply on the website now.

Please note that we can only process applications that are submitted on the website Replying to this post is not sufficient.

Tuesday Mar 02, 2010


Lets face it. It is a cut and paste world out there. I've been amazed at how many people seem to freeze when faced with a blank screen. "Where do I start?"

It seems our programming culture, for better or worse, has become one of programming by example. The internet has made so much code so easily available that its hard to think of something that doesn't have source code readily available. This is both good and bad. It's good because generally sharing makes the world a better place. You can make a lot more progress if you get to reuse other people's code. Many projects become integration projects rather than coding projects. You also get the benefit of seeing other people's code and learning from it - often a great experience. The bad side is that people rarely take the time to understand the code that they are using. This means that they end up with a system that they don't know well, and in complex systems this can lead to unstable or inefficient code.

Well, we aren't going to deny the power of sharing code. Its just too strong a force. After all the entire Sun SPOT project is open source because of this. We do believe that there is a benefit to learning a system with small bite-sized bits of code that are relatively easy to understand. With that in mind, we've created a tool just for sharing, storing and browsing snippets of Sun SPOT code. It can be found in the Sun SPOT Manager Tool under the new "Share" tab. David Simmons, who wrote this code, recently blogged about how to use it. Take a look and let us know what you think.


Thursday Jan 21, 2010

Have any Sun SPOT Developer Stories?

Last year (Feb 2009) at the Yahoo! Hack Day in India, a Sun SPOT-based project created a bit of interest. The idea of Hack Day is to create something interesting in 24 hours and one group used Sun SPOTs to integrate with Yahoo Instant Messenger. Vittal, one of the creators of this hack, recently reposted his blogs on the project and reminded me how fun it is to read about the twists and turns that projects take as pressure mounts.

The back story

The hack

Do you have a Sun SPOT developer story?

Let me know. I'd love to hear your story of projects that didn't end up exactly where you expected, or last minute make-or-break changes that you had to make.

Monday Nov 09, 2009

Scratch your SPOT

Scratch is a great visual programming environment for kids created by some folks at MIT. Randy has put together a little code to connect Sun SPOTs to Scratch and has released a video (below) to show you how to do it.

Its easy and fun! Try it out!


Monday Oct 26, 2009

SPOTs in [near] Space

If you were a high school student on summer vacation before heading to college and you had a little extra time and some Sun SPOTs, what would you do? How about sending a Sun SPOT to near space?

200910231145.jpg 200910231145.jpg


The whole project is chronicled here:

They have made their source code available here:

Hmmm.... It reminds me a bit of another project

Tuesday Aug 18, 2009

Sun SPOT Bling


Those of you who know me know that I'm a sucker for new gadgets. There have been a few new Sun SPOT accessories that I think are worth mentioning here.

Breadboard for the Sun SPOT


First from our friends at Circuit Monkey is the breadboard for the Sun SPOT. In a similar vein to the very popular Breakout Board the new breadboard allows you to have direct access to all the signals from the Sun SPOT eDemo board and provides a nice little prototyping area for you to design your own circuit. I think that Circuit Monkey has another hit on their hands with this one. Its on sale right now for under $30, so its reasonably priced as well. I've been playing with one of these for a while and I must say its very flexible and lots of fun. It brings out all the signals from the eDemo board (A0-A3, D0-D4, H0-H3, Vh, SW1, SW2, 3V ref., 5V ref ). It also includes probe hooks on the sides of the board so that you can easily connect a scope. Vcc is brought out on 4 connectors and has an LED to confirm that you are getting external power. Quite convenient and very useful. You can get it and other SPOT accessories from Circuit Monkey site.

Roomba Meet Sun SPOT


For the robot enthusiasts in the crowd, here is a Sun SPOT add-on that you might like. As you know, on several occasions I've mentioned the IARoc competition where students compete to perform tasks using Sun SPOTs and iRobot Creates. The Create is basically a version of the iRobot Roomba but without the vacuum cleaner part. Its a really great robot platform and with a Sun SPOT to control it, it becomes a really fun platform to program as well. The robot simulator in Solarium is based on this combination. The folks who put on the IARoc competition every year, Wintriss Techncial School, have made their interface available for others to use. It does the level shifting for the serial interface between the Create and the Sun SPOT as well as provides an interface to an ultrasonic sensor. You can buy it from their online store.


Technorati Tags:

Monday Aug 17, 2009

The Tomato Forest (Connecting External Sensors to Sun SPOTs)

An Exercise in Hardware for Software People

A lot of people who use Sun SPOTs are software programmers who are interested in connecting the virtual world of software with the physical world around us. Sun SPOTs are a great platform for this, but often people don't know how to get started. Especially for those of you who have very little experience with hardware, its hard to know where to start. Sun SPOT team member David Simmons has some good "Stupid SPOT tricks" in his blog that help with this. Along those same lines I present here my experiences using Sun SPOTs to help grow tomatoes in hopes that it will give a few software folks the courage to meddle a bit with hardware. You see, we've always had bad luck growing tomatoes, but this year, our plants have been doing much better. Now we are in the tricky time when we need to monitor the water that we feed to the tomatoes to make sure we get the optimal development of fruit. I'd like to use Sun SPOTs to make sure that our watering schedule is appropriate.

Choosing a Sensor

I recently wanted to use Sun SPOTs to monitor our garden. A Sun SPOT with and eDemo board can measure light and temperature which is good, but I was also interested in figuring out whether to not to water the garden. To do this, I needed a moisture sensor that could tell me how wet the soil was. With a little web searching I found the VG400 by Vegetronix. It is fairly inexpensive and seems designed to give me the information I want - soil moisture. The first thing to do when evaluating an external sensor like this is to understand how you interface to it. In this case, the specifications on the web site tell us that it requires 800200908170923.jpg  at 3-12v to operate and that it produces a 0 - 3v analog voltage that varies with the amount of moisture it senses. We can consult the Sun SPOT Theory of Operation to see if this will work with the eDemo board. On page 20 we can see the the eDemo board is able to supply 3 or 5 volts at 100mA. This means we have more than enough power to provide the VG400 the power that it needs. On the top of page 22 we see that Sun SPOT analog inputs A0-A3 measure the voltage range between 0 and 3V. This is a perfect match for the VG400. Theoretically, we could connect up to 4 moisture sensors with a single eDemo board using A0, A1, A2 and A3.

Vegetronix also has a low power version, the VG400-LV, that uses slightly less power (600200908170923.jpg ), but it only puts out 0 - 1.8V. This would also work, with the eDemo board analog inputs, however, it would limit the resolution of our measurement. Here's why. Looking at the equation on page 22 we see:


200908111501.jpg is 3V on the eDemo board. The values will range from 0 - 1023 because it is a 10-bit analog to digital converter and 200908111543.jpg is 1024. This means that a voltage of 3.0V will produce a value of 1023. A voltage of 0V will produce a value of 0. A voltage of 1.8V will produce a value of 614. So the whole range of dry to wet will be represented by values from 0-1023 on the VG400 and from 0-614 on the VG400-LV. That means the scale of the VG400-LV will be compressed into 614 values instead of 1024. Other than those differences the two sensors will be identical. They will connect to the same inputs on Sun SPOT and generally work the same way.


The probe can be used to measure water level and even water volume. The capacitive principle that the probe is based on changes value as the probe is immersed in water. The further it is immersed, the more it changes. This means you could mount several of these in a tank and, with a little calibration, monitor levels inside the tank. I have done only few tests, but it seems quite viable. In the ground, since the water is suspended in the dirt, the probe measures moisture in the area around the probe. Maybe after tomato season I'll try some more experiments to see what other capabilities this sensor has.


Making the Connection

Armed with this information I placed an order with Vegetronix for the VG400. A few days later an unimposing manilla envelope showed up in the mailbox. Inside was the VG400 sensor, just as promised. The disconcerting part was that there was nothing else in the package. No documentation, no receipt, no nothing. For the novice this could be cause for alarm, but have no fear. Closer examination shows that all the documentation we need is conveniently printed directly on the sensor itself. It says:

L1030031.JPGRED: +V



This makes connecting easy. We just connect the red wire to the pin labelled +5 along the bottom row. The black wire is connected to pin A0 (the analog input that we will use in our software. It could just as easily be any of the other analog input pins. Finally we connect the bare wire to one of the pins on the right side labelled GND.


That's it! No circuit to design. No resistors, capacitors or transistors. Instead, its just wires connected to the Sun SPOT. I used a pair of pliers to bend the wires and just poked them into the connector on my eDemo board. For my purposes, a short term installation, I don't even worry about soldering the connections. I just plugged the wires in and let it go at that.



Next step is the software. This too proves to be fairly straight forward. I started with the SendDataDemo. We will use two parts of this demo, the onSPOT part that runs on the Sun SPOT device and the GUIonDesktop part that displays a graph of the data received. We will need to change the code a little in the onSPOT side to make read the analog input instead of the light sensor which is what it reads by default. For a quick and dirty check of our hardware, I changed one line. On line 56 of it gets the lightSensor:

   IScalarInput lightSensor = EDemoBoard.getInstance().getLightSensor();

Instead we'd like to get the analog input:
   IScalarInput lightSensor = EDemoBoard.getInstance().getScalarInputs()[EDemoBoard.A0];

Please note that this is VERY temporary. I should really rename the variable lightSensor to be a bit more descriptive of its new function, but this is just a test. With just that one line change, we can run that code on the Sun SPOT device and connect a base station and run SendData-GUIonDesktop. We get the following output:
You can see that at first the readings were very low. Then I put the sensor in a glass of water and the reading shot up. After about a minute, I removed the sensor from the water and it dropped back down to the approximately the previous value. It looks like it is working!
From here, you can get as fancy as you want, but first lets review what we have accomplished so far. We've gone from identifying a sensor on the web to connecting it by just connecting 3 wires and then changing one line of code in a demo program.. and now we're looking at graphs of data we collected wirelessly. Not too bad!
Of course, for a more permanent installation, there are other things to think about.
One other consideration of some importance is the item in the specification sheet labelled "Power on to Output stable." This is the amount of time between giving the probe power and the time it has valid output. This time is rated at 400mS. Just to be sure I have the enough time, I wake the Sun SPOT up half a second before I take readings from the probes. The Sun SPOT has a nice feature that it shuts the power off during deep sleep, but keeps it on during shallow sleep. This means that I can wake up, disable deep sleep, then go back to shallow sleep while the probe stabilizes.
   sleepManager.disableDeepSleep (); // Assure that we will be awake to power the moisture sensor
   Utils.sleep (STABILZATION_PERIOD); // give the sensor time to stabilize

then later after taking the readings go into deep sleep

   // Go to sleep to conserve battery
   sleepManager.enableDeepSleep ();
   try {
   sleepManager.ensureDeepSleep((SAMPLE_PERIOD - STABILZATION_PERIOD) - (System.currentTimeMillis() - now));
   } catch( UnableToDeepSleepException ex ){
   ex.printStackTrace();     Utils.sleep((SAMPLE_PERIOD - STABILZATION_PERIOD) - (System.currentTimeMillis() - now));

There are a few things to do to make sure that deep sleep works properly:
    • First, make sure that no other applications are running when your application is running. Having multiple threads and isolates is an amazing feature of Sun SPOTs, but if you want to save power you need to keep them under control.
    • Second make sure that OTA is turned off.
    • Third set the routing policy to ENDNODE so that you don't spend energy routing other node's packets
       RoutingPolicy rp = new RoutingPolicy(RoutingPolicy.ENDNODE);
    Based on what I've measured so far, when I set the Sun SPOT to report all the values every 5 minutes I get a duty cycle with over 99% deep sleep. Of the 1% that is left, most of that time is in deep sleep. The moisture probes don't use very much power, so I anticipate several months of operation between battery charges.

    The sensor seems to suit my purposes well. It certainly easy to use. I got a second probe so that I can monitor the moisture in two places simultaneously. This was fairly straight forward. I just had to repeat the process I did for the first probe on a second analog input (A1). While I was at it, I modified the application to send light, temperature and battery levels as well as the moisture reading. I've modified the host side of the application to plot all of these values plus write them out as a CSV file to the disk drive.
    I put a cable tie around the Sun SPOT device to hold the wires in place. Next I screwed an eSPOT mounting clip to a piece of PVC pipe and clipped the eSPOT in place. I put this on the end of a 6 foot tall piece of pipe stuck in the ground. Next I cut the top off an old Costco ibuprofen container and inverted it over the eSPOT. It is waterproof and translucent enough to be able to get diffused light readings right through the container. In fact, in direct sunlight it is still enough to saturate the light sensor. I buried the moisture sensors a few inches down in the dirt.
    Now I have a complete system to monitor light, temperature, and moisture in two locations in the garden. I'm recording data every 5 minutes. Finally I'll be able to collect scientific data about optimal watering schedules. Is it better to have daily short waterings or less frequent deeper waterings? I should be able to find out how long it takes for the soil to return to a baseline condition after watering and from that infer how often I need to water. My goal for now is to keep the soil moisture over multiple days from trending up or down. I want to water enough to keep the over moisture level approximately constant.
       L1030045.jpg L1030048.jpg L1030050.JPG


    Issues and Future Enhancements
    The temperature readings are not very accurate. I know that the built-in temperature sensor is really measuring the temperature of the ADC chip, but I've found that if you have applications that sleep a lot and then take the temperature reading immediately after waking from deep sleep, you can get fairly accurate readings (this only works for eSPOTs that are NOT plugged in. In this case I'm actually using the ADC and I'm taking the temperature reading after waiting for half a second to stabilize the probe. I'll have to play around with this to see if I can get more accurate readings.
    In the future I hope to be able to send this data to a public server where I can view the data from anywhere and adjust the watering schedule while I'm on the road. I'd also like to be able measure the soil temperature early in the season so that I can tell when its time to plant.
    In a future post, I'll make the code available in case anyone else wants to poke around with it a bit more.

    Wednesday Aug 05, 2009

    Location, Location, Location (Radio)

    Location, Location, Location (Radio)

    This post is a follow-on to my previous post about determining location using the accelerometer. That post proved to be quite popular, and at the time I promised to follow up with a post about finding location via the radio. Well that was some time ago, but finally, here's more about location. This time, as promised, we will talk about how to derive location from a radio. Can you tell where a Sun SPOT device is, using its radio? As with the accelerometer, unfortunately, the news isn't very good. Its quite difficult to get an accurate position from the Sun SPOT radio, but we'll talk through some of the techniques used to figure out where you are in radio space. We'll talk quite a bit about radio propagation. We'll toss in a little math, but nothing too complicated I promise. I hope you enjoy it.

    Generally, to find a location using the radio, we want to find our position relative to other devices of known location. There are two basic techniques. Either we need to figure out the distance and bearing to another device of known location (a vector), or we need to find the distance to multiple devices and triangulate to infer a location.

    Direction and Distance to a Known Location


    In the first technique we need three things to establish the location of the Sun SPOT. We must know the 1) Bearing and 2) Distance to a 3) station of known location. In the diagram above I call the station of known location station, "Home Base." In order to figure out its bearing we need to calculate an angle relative to a known direction. If we had some way to directionally detect radio waves, we could use a magnetometer to get an absolute direction to compare to and then calculate a bearing off of that. Of course, this would mean that we would need to use a directional antenna or other means of determining the direction of the radio signal from the Home Base. Since we don't have a servo controlled, directional antenna on the Sun SPOT, nor a magnetometer, this is very difficult to measure.

    Distance to Multiple Known Locations


    Since direction is not likely to be an easy thing to calculate, we can take another approach. Perhaps it would be easier to determine our position by simply using distance to multiple known locations. In the image above, if we know that we are 100 meters to Green Base, then we know we are somewhere on 100m diameter sphere (remember radio waves propagate in 3 dimensions, not just a two dimensional circle) with the Green Base as a center. If we also know that we are 80 meters from the red base, then we know that we are somewhere along the intersection of the green sphere and an 80m diameter sphere with the Red Base as a center. The intersection of two spheres is an ellipse, with three spheres you get two points and finally with a known distance from four other devices, you should be able to pinpoint your location. Of course, most methods of measuring distance in the real world are not completely accurate, so more distances makes for more accuracy in your estimation of position.

    One common problem with this technique is that it usually takes time to get these distances. To put it another way you cannot get all the distances simultaneously. If you move between measurements it will affect the accuracy of your estimate. The process assumes that you don't move between measurements. So we must either assume that both our device and the devices we are measuring are stopped during the measurement or apply a level of uncertainty relative to the total amount we and the reference locations could move during the measurement.

    Time of Flight

    Great, now we've reduced the location problem to just being able to measure distance. This should be easier right? A logical way to measure distance would be by calculating "time of flight" of the radio signal. In other words, calculate how long it takes the signal to get from transmitter to receiver. Let's take a look at this. Radio waves propagate at the speed of light or about 299,792,458 m/sec. This means that a radio wave covers one meter in about 0.000000003334 seconds or just over 3.3 nanoseconds. So, it can cover 3 times the radio range of a typical Sun SPOT in a single microsecond. One thing for sure is that we will need very accurate timings if there is any chance of getting reasonable accuracy to our measurements. The current eSPOT has a 180 MHz clock, or just over 5.5 nanaoseconds/clock. This means that every clock cycle corresponds to about 1.7 meters of radio propagation. Furthermore, the IEEE 802.15.4 radio standard that the eSPOT uses can transmit at 250kbits/sec. That means that a single bit has nearly 1200 meters between its start and finish. Or to put it another way, since the Sun SPOT range is roughly 100m, the start of a bit is always received long before the end of a bit is sent. This isn't strictly true because IEEE 802.15.4 radios use a more complex coding scheme than just sending a bit as an on or off (I explain this amore below), but the point still stands. A bit is much too large a resolution within a few meters.

    For this method of measuring distance to have any chance of working we must measure the onset of the leading or trailing end of a bit - some sort of an instantaneous synchronization signal. It would be quite difficult to get any accuracy at all if any software were in the loop because timing is so critical. In order for this to be practical, we would need to have the ability to time tag arriving packets in hardware and not wait a potentially variable amount of time for something like an interrupt to get serviced. Additionally, we would probably need something similar on the output so that we could time tag packets as they are actually being sent. Its not good enough to time stamp them as they are put into the queue to be sent, they would need to be stamped as they are sent out.

    However, even if you were able to get the exact time that a packet leaves one device and the exact time that it is received by another, there is still the problem of synchronizing clocks. It would appear that we would have to have clocks that are synchronized to the nanosecond. This seems like another very difficult task until you consider the following. Lets assume that at time 200908060649.jpg Sun SPOT device 200908060651.jpg has a clock time of 200908060646.jpg while Sun SPOT 200908060647.jpg has a clock time of 200908060652.jpg. At exactly this moment, 200908060651.jpg sends our synchronization signal over the radio. We would like to know the propagation time 200908060657.jpg . We know that 200908060647.jpg will receive the signal at time 200908060700.jpg where


    the problem is we don't know 200908060653.jpg. We don't know the exact reading of another Sun SPOT device's clock at any given time. Either together with the synchronization signal or in a separate message 200908060651.jpg can tell 200908060647.jpg what time it believes the signal was sent (ie 200908060646.jpg). Since the clocks are not calibrated, this may have little relation to the time on the other Sun SPOT device. Using the information available to it, 200908060647.jpg could calculate a preliminary propagation time (200908060658.jpg) as:


    Unless by dumb luck the clocks are synchronized to the nanosecond (not likely), we know that 200908060659.jpg is incorrect. Let's suppose further that the difference between the two clocks is 200908060640.jpg .


    We know that the true propagation time, 200908060653.jpg, is different from the calculated one, 200908060659.jpg, by 200908060640.jpg .


    We really need to know the difference in the clocks, 200908060640.jpg , before we can calculate the true propagation time, 200908060657.jpg . Suppose that we repeat the experiment going the opposite direction. Then if we assume that the clocks do not drift with respect to each other (a big if at this level) and that the next synchronization signal is sent at 200908060704.jpg and received at 200908060705.jpg then we get:


    Now if we make further assumptions that the devices have not moved and that the speed of light has remained basically constant (which for our purposes it is probably reasonable to assume), then we can assume that the propagation time 200908060712.jpg is also incorrect by 200908060640.jpg but in the opposite direction.






    Therefore now that we know 200908060715.jpg , we can plug it in to get the true propagation time:


    These values can be measures, so new we have the true propagation time, 200908060710.jpg . Now we just divide by the speed of light to get the distance in meters:


    This means that in theory, with proper hardware support we should be able to determine the distance to another device by measuring the time of flight of the radio signal. Practically however, even with hardware assistance, its hard to see how we would get more than about ten of meters of accuracy under good conditions, which is one tenth of the range of an eSPOT. Actually measuring with this precision and accuracy proves quite difficult.

    However, our problems with this method aren't over yet. To most computer scientists, the idea sending a bit over a radio seems quite natural, but actually radio waves aren't digital. Digital bits are a convenient simplification that we apply to the real analog world. The signal that is sent is not a bit but an analog encoding of a bit. In 2.4 GHz IEEE 802.15.4 radios used by the eSPOT, data is encoded using Offset Quadrature Phase-Shift Keying (OQPSK). This encoding scheme must be decoded by the receiver and turned into bits. As the signal travels in the air and is affected by its surroundings, other signals and general noise, the characteristic of this signal can change. This means that the receiver needs to do some work to interpret the signal it is receiving. It needs to listen to it long enough to interpret what it is hearing. While this happens very quickly, the time required to notice the signal changes could actually vary slightly depending on the shape of the received signal. Even a few nanoseconds of variations will affect the accuracy of our distance estimations.

    The current eSPOT hardware does include some ability to time stamp received packets in hardware, but its not clear to me that is has anything like the required accuracy or precision for the task of measuring time of flight.

    Distance From Signal Strength

    This leaves us looking for other ways of measuring distance using the radio. Perhaps the most promising is the use of Radio Signal Strength (RSS). It seems intuitive that RSS and distance transmitted are related by the inverse square law. In theory as distance goes up, RSS goes down and vice versa. As I've often found in life, the difference between theory and practice in much greater in practice than it is in theory. In the real world we find this is not strictly true.

    One of the early programs that we wrote for the Sun SPOTs was a simple Therimin simulation. The Therimin is a unique electronic instrument that lets the user play music by waving their hands near two antennas that protrude from the device. One controls the volume and the other controls the pitch. Our version was inspired by this, but quite a bit simpler. It simply translated RSS values between two Sun SPOT devices into pitch values for a MIDI synthesizer. Unfortunately, we found it very frustrating to play because there was no strict mapping between distance and the notes that were played. We could start with the two Sun SPOT devices far apart and then slowly bring them together. We would expect this to create an increasing musical scale on the MIDI keyboard. While it was true that holding the SPOTs close together would cause a high note to play and holding them far apart would cause a low note to play, the transition from far to near was full of ups and downs. We double checked our code, but everything seemed to be in order. What was going on?

    The problem was that radio propagation is fairly complex thing. At the 2.4GHz frequency range that the eSPOT uses for its radio, the signal propagates by line-of-sight. This generally means that if two eSPOTs are within visual range of each other and <~100m from each other, then should be able to communicate. The problem is that many factors can affect this signal propagation. Early on in the life of the Sun SPOT project, many of our demonstrations would be working perfectly until a crowd of people entered the room to see the demo. We experienced our own little version of a Heisenbug (a bug whose behavior changes when you try to observe it). These, "ugly bags of mostly water" (as Enterprise computer once referred to humans) tend to absorb radio signals. Remember that microwave ovens work in a similar frequency range. The eSPOT radios don't put out anywhere near enough energy to cook a hotdog or much or anything, but people and other water based items in the vicinity can absorb signals. Our observers changed the radio characteristics of our demonstration area just enough to upset our demo.


    It turns out that line-of-sight propagation is much more than it may seem. A Sun SPOT does not have a highly directional antenna, so it transmits in all directions, not just toward the intended receiver. While some of this signal finds its way directly to the receiver, more of it will wander off in other directions. If one of these wandering signals bounces in such as way that the bounced signal also finds its way to the receiver, it will have taken a slightly longer path to the receiver than the direct signal. Because of this, it will arrive slightly out of phase with the direct signal. When a signal is received along two or more different routes, the condition is called multipath propagation. The receiver receives a mixture of these tow signals. The amount that the multiple paths affect the signal will change depending on the amount of delay and the strength of the signals experiences being mixed, as shown in the figures below:


    The receiver will receive a signal that is the direct signal and the reflected signal mixed together. In mathematical terms this means the signals are added. The first graph shows two signals that are received slightly out of phase with each other (the same signal, just delayed slightly) and the red line is the sum of these signals. The RSS is measured as the amplitude (difference between the lowest and highest values) of the signal received. As you can see, the red line has more amplitude, and so a device receiving this signal will register a stronger signal strength than a device just receiving a direct line-of-sight signal. However, the signals don't always mix in a way that has a positive effect on signal strength.


    Sometimes the way these signals add has a net negative effect on the signal strength. In the second graph, the two signals in black add to produce a red signal that has lower amplitude (and signal strength) than either signal individually. They are canceling each other out. You can imagine a situation where the reflected signal is delayed by exactly half a wavelength and thus effectively cancels the original signal completely. In addition to the phase shift caused by the delay, there is usually a bit of difference in amplitude between the signals because the direct signal is usually stronger than the reflected signal. This, and the fact that there are usually many reflected signals, will often keep the signal from being completely cancelled out, so in practice signals will vary significantly and in ways that are difficult to predict, but rarely will cancel completely.

    There is something called the Fresnel zone (pronounced fray-NELL) that is an ellipsoid area around of the direct line between two communicating devices. 200908031938.jpgThe zones help to define the effects of the reflections. You can calculate the size of radius of the Fresnel zone with the following equation:


    where 200908060720.jpg is the distance in meters between the devices, 200908060643.jpg is the frequency in GHz, 200908060719.jpg is the Fresnel zone and 200908060718.jpg is the radius in meters. So for example, if two Sun SPOT devices are 100m apart, and they use the built-in 2.4GHz radios, we get a value for 200908060718.jpg of 1.77m for zone 1. This is the radius of the zone at its widest point (in the middle). Reflections in Fresnel zone 1 tend to cancel the original signal. Along an ellipsoid shape that is zone 2 (2.5m in our case) the signals will tend to add. Fresnel zone 3 would produce an 200908060718.jpg value of 3.06m, and so on. In general, reflections in odd numbered zones tend to cancel the direct signal while signals in the even number zones tend to add to the signal strength. It is good to keep at least Fresnel zone 1 clear if possible.

    Of course, if the two devices are closer together, then200908060719.jpg is smaller. So, for example, if the two devices are only 1 meter apart, then zone 1 200908060719.jpg would be a mere 17cm. Zone 2 would be 25cm. So moving something reflective to radio waves that is half way between the two devices only 8cm can make the difference between a very strong signal and a very weak signal. Of course, something closer to either device (the end of the ellipsoid) would have to move even less to have a similar effect. Near either of the devices, something moving only a few centimeters could completely change the signal characteristics. Similarly, moving a Sun SPOT device only a few centimeters could completely change the characteristics of the multi-path signal that is reaching it.

    We can construct a hypothetical extreme case. The wavelength of the radio signals sent by the eSPOT is about 12.5 cm. This means that in the extreme case of a direct signal and a reflected signal of equal amplitude at right angles to each other, you can go from double signal strength to no signal at all in half a wavelength which is just over 6 cm. Note that this will be true regardless of how far away the two devices are from each other. This makes it very difficult to find a correlation between distance and Radio Signal Strength.

    This brings up another question about these radio waves. What types of materials will affect the propagation of a radio signal? We know that they travel optimally through open air (or a vacuum). We know that, at this high frequency, many things tend to affect the signal. In general, metal will reflect signals and water will absorb it, but most things will do some amount of each. Plastic, paper and drywall tend to have little effect on the signal since they aren't metallic and have little water in them. A metal white board in a room can have a large effect on radio propagation. One of the most important materials is the ground. It can both absorb and reflect. Reflections from the ground are a common cause of interference. If we want to keep Fresnel zone 1 clear and get 100m of transmission, then we know from the calculation above that we need to keep them at least 1.7m off the ground and would prefer to be closer to 2.5m.

    The story gets even more complicated when we look more closely at the what is going on. There are three phenomena at work when the radio waves encounter a an obstacle: reflection, diffraction and refraction. We discussed reflection earlier. Diffraction occurs when a wave passes by an obstacle or through a small opening and appears to bend. Refraction is the change in direction as a result of a change in speed of a wave as it travels through different media. Refraction is the least common since the speed of light is fairly constant within the realm where we working. However, the diffraction has a real effect. In particular, there is a phenomenon called Edge Diffraction that applies to radio propagation in these frequencies.


    Imagine a Sun SPOT device transmitting a signal over a an open area with a single obstruction in it that can block the radio waves. One would expect that the obstruction would create a a radio "shadow" where no signal can reach. Instead, the signal at this point creates a new wavefront at the edge of the obstruction that propagates into the shadow area providing a weak, but sometimes usable diffracted signal. The area of direct propagation just beyond the top of the obstruction now exhibits an interference pattern with the refracted signal causing sporadic losses in the area labeled diffraction loss. Also, some of the signal will be reflected and this will create an interference pattern with the direct propagation wave in the area in front of the obstacle. All these affect signal strength. A similar condition occurs with a radio signal goes through a small opening. Diffraction occurs at the edges and interference patterns result that cause difficult to predict changes in signal strength.

    If we want to get really esoteric, there are atmospheric conditions that can affect signal propagation. For instance humidity in the air can affect signal strength. Remember, water tends to absorb radio signals. This means that in addition to objects in the vicinity of the propagation path, even changes in the weather can affect signal strength. This effect is usually not as strong as some of the others mentioned above, but is can be noticeable. In some cases it can cause an effect known as Tropospheric Ducting where signals find paths through "pipes in the sky" created by certain atmospheric conditions that can go on for thousands of miles. This can cause otherwise line of sight signals to travel great distances around the earth. I've never heard of anything like this happening with a radio signal from an eSPOT, but it does show the counter intuitive nature of radio propagation. Besides, "Tropospheric Ducting" is just a cool term to be able to throw out in conversation, so I thought I'd tell you a little about it.

    Radio Space Shape

    eSPOT Antenna Radiation Pattern

    As if all this weren't enough, most of these schemes assume a uniform signal radiating in all directions from the Sun SPOT device. This is simply not true in practice. The diagram at left shows the actual measured propagation pattern of the eSPOT antenna. If it were very uniform, we would see a spherical shape. Instead we see an indescribable shape with all sorts of different lobes and divots. You can see a > 10dB difference between the strongest and weakest edges of the signal. This means that you can change the signal strength can easily more than double just by changing the rotation of the Sun SPOT device. So the orientation of an eSPOT is very important in controlling for signal strength.

    Of course, given what we've learned about diffraction and reflection of radio signals, you can see that this also means that in some cases a stronger signal may be aimed as a reflection rather than a direct route which will cause all sorts of confusion when it comes to signal interference and cancellation.

    So where does this leave us? Just like with the accelerometer, finding the location of a Sun SPOT using the radio does not look very promising. In theory, we might be able to determine location if the following conditions were met:

    1) There are no obstacles anywhere near the Sun SPOT devices or the area between them (for many Fresnel zones) that could reflect, refract, diffract or absorb the signal.

    2) The Sun SPOT devices are many meters off the ground

    3) The Sun SPOT devices do not change orientation with respect to each other.

    4) The Sun SPOT devices don't move between measurements

    If ANY of these rules is broken the result is a radio space that is for all practical purposes nearly impossible to predict. On a large scale, the closer devices are the greater their signal strength, but locally this will not hold true.

    I'd be happy to be proven wrong. As always, all my gloom and doom may inspire someone to figure out a good way around these limitations and prove that you can measure location with radio and/or acceleration. Sometimes there is no greater motivation than saying it can't be done. Have fun. In the mean time, if you get unexpected readings of radio signal strength, now you may at least have an idea why it is happening.

    I stand by now for your questions and comments.

    Thursday Jul 30, 2009

    Sun SPOT V5.0 Red Release

    Sun SPOT V5.0 Red Release

    Its been a busy summertime so far and I realized that I haven't yet mentioned our new release here... so, here's the scoop: The new v5.0 Red release is available now from SPOTManager.  As always, remember it includes an emulator so you can play with it even if you don't have any physical Sun SPOT devices.

    Here are a few interesting things to check out in the new release:


    Updates to Solarium

    Solarium includes several new views that add significantly to its usefulness. Radio View, Robot Simulator and Deployment View. Each is described below. Also, there is a new demo that shows how to add your own extentions to Solarium (SolariumExtensionDemo ).

    Robot Simulator



    Solarium now includes a robot simulator that lets you program a virtual Sun SPOT-based robot to navigate a maze and other virtual obstacles. These robots are based roughly on the iRobot Create which is a fine little robotics platform used in the IAROC competition among other things. From Solarium, simply open the RobotView and then click on "Add Robot." This will create a robot and virtual Sun SPOT to control it. You can even run multiple robots at the same time in the simulator. Its quite fun. Try the tutorial here.



    Radio View give you a visualization of the radio space of your Sun SPOTs. Its tells you which devices can talk to each other and the relative signal strength of the connection in each direction. This makes it much easier to construct multi-hop experiments and understand issues with your network topology. Click on a node to get information about its transmit power, MAC filtering and routing manager. Click on a link to get information about the strength ofJust open a Radio View from within Solarium to try it out.

    Deployment View

    Deployment View is a tool for managing the code on networks of Sun SPOT devices within Solarium. Think of it as a three things, an abstract way to define your network in terms of the roles that the different devices on your network, a way to assign devices to those roles and finally a distributed make-like tool for keeping the software up to date on your network. For example, I do a lot of demonstrations that including showing off the Bouncing Ball demo. Abstractly I can set up a deployment that includes two Sun SPOTs that each play the role I'll call ball bouncers. When I need to do a demo I can pick any two Sun SPOTs that happen to have charged batteries and OTA and assign them to these roles. Then I simply click the "Deploy & Run All" and the appropriate code is deployed to the Sun SPOTs that I have assigned. The power of this tool becomes apparent when imagine more complex scenarios where many devices have many different roles. Individual Sun SPOT devices can have multiple roles and individuals roles can be assigned to multiple devices for flexibility.The real place that this tool shines is during development. Here it acts like a distributed "make" tool. When you change your source code, the deployment view will figure out which of your devices need to have been affected by the changes you made to your code. It will then automatically deploy and start the new code to the devices that need updating. This means that a single click of a button can update the code to your entire network. This tool is in its infancy, so we hope to get a lot of feedback on how it could evolve to be more useful.

    Radio Stack Improvements - LQRP

    This release includes major improvements to the reliability of radio transmissions. Additionally, the radio stack includes a new default routing protocol called the Link Quality Routing Protocol (LQRP). This routing protocol takes into account the not just connectivity, but also the quality of the connections when choosing a route. Previously, the system would choose the route with the least number of hops. Sometimes that would include long hops that had very poor link quality. Now the protocol includes the intelligence to choose a route that makes uses good quality links in order to maximize the overall quality of the link. This change is not interoperable with previous releases of Sun SPOT software. In fact, can show some confusing behavior because broadcast is compatible between V4.0 Blue and V5.0 Red while direct messages are NOT compatible. This means that protocols use broadcast to find services and then follow up with direct messages will get confused unless all participants are running the same version of software.

    Crypto Library

    The Sun SPOT platform includes advanced cryptographic capabilities. Many people don't even know that they are using Elliptic Curve Cryptography every time they deploy code to their Sun SPOTs, but they are. The system verifies the owner and validity of the code during deployment.

    Now there is a demonstration of the SSL library for the Sun SPOTs based on the code in Sun's reference implementation of Java ME for cell phone. The Sun SPOT SSL library includes support for TLS 1.0, support for server-side SSL/TLS, support for Elliptic Curve Cryptography cipher suites (for now, only ECDH-ECDSA-RC4-SHA and secp160r1 are supported).

    SPOT Web

    SPOTWebDemo is a host application that starts up a simple web server and lets remote users interact with a collection of SPOTs in the vicinty of the attached basestation using a standard web browser. Authorized remote users can monitor the state of sensors, applications and other system statistics. They can also install, start, pause, resume, stop and remove applications. This allows you to do many of the functions that you would do in Solarium, via a standard web browser.


    Many applications on Sun SPOT devices collect data. Yggdrasil is a data collection framework to allow you to stream sensor data to a centralized repository. The demo provides libraries and sample code to use the framework. The way that Yggdrasil works, the Sun SPOT sends sensor samples to host for the first time. The host does not recognize the sensor, so it queries the Sun SPOT. The Sun SPOT responds with handshake information and metadata about the sensor. Now the host knows about the sensor and begins to print out the sample data as it arrives.



    AirStore is an experimental shared data repository for Sun SPOT applications. It is designed to make a common usage of Sun SPOTs much easier... sharing simple data. Currently, when you write a program and want it to share data with another Sun SPOT over the radio, you have write some code to set up and transmit your data. Similarly, you have to write code to receive the data on the other side. AirStore attempts to make this much easier. With simple one line puts and gets, distributed applications can share primitive Java data types. One Sun SPOT application can set a variable x with

    AirStore.put(x, 17);

    and another can get x with

    int x = AirStore.getInt(x);

    The system works in cases where all devices are within broadcast range of each other and do not sleep. Thus for UI experiments or simple robot control, this method can work well. The data types supported are: int, double, String, boolean, byte, long, plus arrays of these types.

    If you look in the demos folder you will find documentation, and inspector (host application) as well as several example programs including a rather interesting integration of Sun SPOT with a popular programming environment for kids called Scratch.

    Other Enhancements

    TWI (two-wire interface) is now supported to both the eDemoBoard and main ARM9 processor board.

    You can now limit received radio packets to those from a sender on a whitelist or not on a blacklist.


    Roger Meike, Senior Director of Area 51 and Director of Operations Sun Labs


    « July 2016