Since the release of Windows 7, I’ve heard plenty of good reviews about this latest Windows version and I decided to give it a try.  A month ago, I installed it on my MSI netbook so I could travel lightweight and give a paper presentation using PowerPoint.  Shortly thereafter, Ubuntu released its latest version into the wild and after using both Windows and Linux for about a month, I’ve been able to come up with some strong and weak points on both.  Some of my comments apply to Windows and Linux in general and not just to these latest versions or distributions.

Windows 7

Pros

• A solid UI.  I’m a real fan of the Aero theme, system fonts, and improved start menu.  The taskbar really takes the cake by using icons and clustering multiple instances of the same program.  Hovering over the taskbar gives a cool preview of each open window.
• Fast.  My netbook with Windows 7 feels just as responsive as it did when it ran Linux.  Boot times are a little slower, however.
• Robustness.  I had no difficulty with the Windows 7 install on my netbook and Microsoft even provides a Windows 7 CD to USB image utility for netbooks.  Unlike my Ubuntu experience, there aren’t any weird hacks to go through in order to get your display or wireless connection working correctly following a fresh install.  Furthermore, I haven’t encountered any system crashes and Windows seems to keep any malfunctioning program from taking down the whole system.
• Good hardware support.  I plug in a camera and it’s automatically recognized and drivers are installed from the internet.  I plug in an external monitor or projector and the correct model is detected and my desktop is extended on to it with the correct resolution.  It’s great for presentations since there isn’t much fiddling with the projector or Control Panel settings to get everything looking good.
• Software availability.  Everything has a Windows version, even most open source software.  I find that most developers put more effort into Windows versions since that’s what most people are running.  For example, I’ve had fewer crashes and slowdowns with the Windows versions of Firefox and Skype.  The Windows version of Skype is also much more polished than its Linux counterpart.  Furthermore, many software programs are only available on Windows.  MS Office, despite its incredible price tag, is still far superior to Open Office, and of course, only runs on Windows.
• Games.  Most of the latest AAA titles are available for Windows, a few might be available for Mac, and I’ve heard of only one or two released right off the bat for Linux.  If you’re into PC gaming, Windows is the only way to go.

Cons

• Lack of a centralized software repository.  This makes it a real pain to download and  install software since I have to go to a separate website for each program I want to install, find the download page, and click through a bunch of installation dialogs.  Even worse is that nearly every Windows program I install runs a background process on startup that constantly checks for updates and bogs down my system.  Also because of this lack of a centralized repository, programs inconsistently install themselves in many different places.
• Difficult to configure system settings.  The Control Panel is a real maze of links, buttons, and dialogs which are dumbed down at the highest level and utterly confusing once I drill down into specific settings.  Some settings can’t even be accessed with the Control Panel: for example, I still find myself using msconfig.exe to remove unwanted startup items.
• Windows Update is still very intrusive.  A large number of updates require me to reboot and will display a nag timer forcing me to do so.  I really don’t like the OS to get in the way and nag at me.  Some of the system updates take quite awhile to install and can bring my system to a crawl.
• Libraries.  This feature, which wasn’t in XP, is similar to Unix symlinks.  A library clusters together files and folders from several locations in the filesystem, making it unclear where the files are really located.  I would prefer that all my music, movies, or PowerPoint slideshows be stored in a single location in the directory structure such that I can easily back everything up or find something via Windows Explorer.  Windows seems to want you to not have any knowledge about its directory structure and instead rely on searches and libraries.
• Developer Tools.  This is the exception to the software availability and quality rule.  I’ve been using Eclipse for Linux and Windows and it works well enough on both platforms with plugins for Subversion and LaTeX editing.  However, other tools such as a basic text editor, LaTeX compiler, and command line tools such as make are either lacking or nonexistent.  I find it much easier to work with the command line than a GUI when creating plots with Gnuplot and documents with LaTeX.  I can quickly switch from one thing to the next without clicking through a whole pile of menus and dialogs.

Ubuntu 10.04

Pros

• A centralized software repository.  This is the main reason I like Debian and its variants so much. “apt-get install” will give me any program I want and provide automatic updates.  Removal is just as easy.
• Fast boot times.  On my 3 year old laptop, Ubuntu is up and running in 30 seconds or less from the moment I hit the power button.
• Easy to configure and control.  Adjusting a system setting is easily performed from a GUI tool or from the command line.  Configurations are stored in well documented text files as opposed to the nasty Windows Registry.  It’s really easy to track down where a program’s install directory is located and tweak something.
• A customizable UI.  The sheer number of themes available is astounding, with Compiz providing some really cool desktop visual effects that rivals anything Windows has to offer.
• Enthusiastic user base (support).  I’ve found that tons other Linux enthusiasts are more than willing to help with problems on message boards and websites.  For things I’ve had trouble with, a quick google search or message board post will return tons of answers with other people who had the exact same problem and had already solved it.  With Windows issues, answers seem a lot more difficult to come by and the user base isn’t nearly as friendly.
• Developer Tools.  Just about everything under the sun is readily available for developers in Linux, including a plethora of compilers, text editors, and command line tools.  Working from the command line makes things a snap compared to painstakingly navigating through different dialogs and menus.

Cons

• New software versions take time to be added to the repository.  For example, Firefox 3.6 has been out for months but was only recently included in the 10.04 Lucid Lynx release.  Prior to that, I had to compile and install Firefox 3.6 from source.
• Installation headaches still persist.  With every Ubuntu release, something doesn’t work post-install.  With 10.04, it was my video drivers.  During the upgrade process from 9.10, the installer whined about my video drivers and supposedly aborted the install.  Upon rebooting my computer, however, it was clear that the install had not aborted and my display was completely messed up.  After rebooting again, Ubuntu downloaded and installed the required video drivers automatically.  Also, Ubuntu now tries on boot to mount a remote drive in my /etc/fstab for which I don’t have a saved key, halting the boot process until I manually override the mounting process.
• Software quality and robustness.  Productivity software, such as Open Office, isn’t nearly as capable or as featureful as Microsoft Office.  I’ve had trouble with Flash causing browser crashes and other programs crashing all on their own which run stably in Windows.  I’ve had a heck of a time figuring out why some fonts are rendered terribly and look blurry in some programs, among other things.  More effort should be placed on creating polished products in order for open source software to really take off.
• Lacking hardware support.  This goes with the above bullet: I plug in an external monitor or projector and I still have to fidget with resolutions and positioning to get everything to work.  Suspending to disk often borks the external monitor configuration and then I have to do it all over again.

In all, I can’t say that either the latest Windows or Linux versions are better.  Windows provides a more robust and polished solution, while Linux gives more power and control to its users.  I find Linux to be a better choice for development, but Windows is the clear winner for gaming.  Both Windows 7 and Ubuntu 10.04 run reasonably fast — Windows 7 does quite well on my netbook, but Ubuntu clearly takes the cake with boot times.  Until open source software takes quality up a notch and Windows provides a better development environment, I’ll probably be dual booting, running virtual machines, or using multiple computers with both operating systems.

The TinyOS serial stack is designed to work with Active Messages so that packets received over the radio can be easily forwarded on to the PC.  To that end, the high-level serial and radio components provide the same interfaces.  The TinyOS serial stack has layers for packet formatting, error checking, and a read/write buffer.  However, for our project, we wanted to simplify the PC side so we didn’t have to use the TinyOS JNI libraries to receive TinyOS Active Message packets.  A simple program to read ASCII characters over the serial connection would suffice for our purposes — Minicom does this quite well and is easily installed on Ubuntu Linux and can be configured to read from attached USB devices.

The goal was to produce a TinyOS component that provided a command for transmitting ASCII character strings over the serial connection to a PC.  The  implementation is very similar to the Pulse Oximeter code I wrote for Atmel-based devices, however this time I targeted MSP430-based devices, such as the TelosB or Tmote Sky.  The implementation uses the Msp430Uart1C component for accessing the serial connection. This component provides the UartByte or UartStream interfaces for reading and writing and the Resource interface for gaining control of the UART. Msp430Uart1C also provides the Msp430UartConfigure interface for setting the baud rate.

The control flow for writing a character string is as follows: First, request the UART resource. Second, when the resource has been granted, call UartStream.send() to transmit the string. Lastly, when UartStream.sendDone() is signaled, signal the higher level application that the character string has been sent or an error message if something went wrong. In my SerialAscii module, I have the following command to send a character string:

  command error_t SerialAscii.sendAscii(char *str)
  {
    bufferLength = strlen(str);
    if(bufferLength > BUFFER_SIZE)
      return FAIL;
    memcpy(strBuffer,str,bufferLength);  // copy string into a buffer
    call Resource.request(); // request access to the UART
    return SUCCESS;
  }

I copy the string into a buffer to keep the application from modifying it before being transmitted. When the resource request is granted, I transmit the string:

  event void Resource.granted()
  {
    error_t result = call UartStream.send(strBuffer,bufferLength);
    if(result == FAIL)
      post sendDoneFailTask();  // return failure message to the user if something bad happened
  }

Lastly, when the string is sent, I release the resource and signal the higher level application:

  async event void UartStream.sendDone(uint8_t *buf, uint16_t len, error_t error)
  {
    // call Resource.release() in each of these tasks
    if(error == SUCCESS)
      post sendDoneSuccessTask(); // signal SerialAscii.sendAsciiDone(SUCCESS);
    else
      post sendDoneFailTask(); // signal SerialAscii.sendAsciiDone(FAIL);
  }

I’ve made my code available here. Let me know if you find any bugs or have any comments or suggestions.

I tried desperately to fix the fonts, summoning the help of the Ubuntu forums.  I tried editing font rendering settings in my local .fonts.conf.  I deleted the font cache and reconfigured fontconfig.  I tried adjusting a font quality parameter in Firefox’s about:config. For some forums posters, these solutions worked.  For me, nothing seemed to help.  Finally, I was able to get Firefox 3.6 installed with normal fonts by downloading and compiling the source code and installing the binaries compiled on my own system.

I’m not the only one who is frustrated by this.  This was probably the first time I’ve resorted to compiling a third party application from source since first using Ubuntu and Debian in 2006.  Normally, it’s just apt-get install whatever program you want.  The package manager automatically updates everything and keeps out of my way, rarely nagging to reboot unless the kernel was updated.  The package repository was one of the main reasons I switched to Linux in the first place: an easy, single step way to install anything and keep it up to date.  No hunting for a download website somewhere on the internet or clicking through a bunch of dialogs in an install wizard.

With such lag before new third party applications get added to the Ubuntu software repository, plenty argue that Linux isn’t ready for the mainstream.  I agree completely.  Most people will have to go through similar steps as I to get many of the latest third party applications installed, and it can be a real pain.  However, in Linux, I am free (as in speech) to customize or rewrite any part of the operating system and share my changes with others.  It also gives me a free (as in beer), top notch development environment for my work.  The problem is that such freedom comes at a cost: tinkering to get everything to work correctly.  Every time I’ve upgraded to the latest Ubuntu version, something doesn’t work and has to be fixed.  In another example, I recently installed the netbook remix version on my netbook and was rewarded by a flickering screen, which was fixed with a BIOS update.

Mainstream users just don’t want to be faced with flickering screens and BIOS updates, they want something that just works.  Consequently, they are willing to give up some of that freedom (as in speech and beer) to have a device that boots normally and doesn’t have font rendering issues when they install the latest version of a program.  Such users are better off with an Apple, and indeed Apple charges them a price in terms of money and control.

The iPad has launched a storm of controversy over its lack of user control.  Essentially, the device is a large iPhone, except there is no phone.  All applications must be purchased from the Apple-controlled App Store.  The real question is: do  mainstream users really need fine-grained control over their devices?  One comment on a Slashdot post really makes an interesting argument:

What has choice done? It’s given us the chaos of spam, malware, worms etc…  The average consumer should get a locked down device such as what Apple are proposing, a limited device with a closed market. And you do realise this is really no different to a games console.  Full blown computers should be reserved for those of us who know how to manage them responsibly…Computers as they are today are simply too complex and difficult to manage for the average consumer, so you either give them something simple or you take the management out of their hands.

Combined with the “Linux is not for mainstream” argument, this really makes the case that perhaps devices that work well but allow little user freedom may be the best for most people.  Most of the time, it’s the best choice for me.  I’ve got a phone, media player, GPS device, and others that I want to just work and perform a very specific function.  In these cases, I would rather they perform their jobs reliably than be extensively customizable.  However, I do think that the option to exercise greater control should be there for those who want it, no matter how few.  In the case of PCs, I’ll take that option, stick to Linux, and keep compiling from source when I have to.

Prior to writing the driver/interface code, I had to procure the pulseox hardware.  Detailed descriptions of hardware, software, and applications are found at the Harvard CodeBlue website.  I first ordered a Smiths Medical OEM Digital Micro Power Pulse Oximeter Board.  I was able to get in contact with sales staff by emailing Smiths Medical.  The pulseox board comes with a finger sensor and runs about $200.

Next, I needed an interface board to connect the BCI pulseox board to the 51 pin connector on the Crossbow IRIS.  The Harvard CodeBlue source code has documentation for a PCB layout and suggests that you order the PCB from an online manufacturer.  You also have to purchase some other components that must be soldered onto the interface board.  Fortunately, I was able to “skip” this step with the help of Leo Selavo, who graciously supplied me with two interface boards.  He emphasized that soldering the components onto the interface board requires a lot of skill and experience and if I were to try on my own that I would most likely break the PCB or components several times until I got it right.  The setup with pulseox board, interface board, IRIS mote, and finger sensor is illustrated below:

Pulse Oximeter on IRIS

With the pulseox board, interface board, and of course IRIS mote, I was ready to get my heart rate.  The biggest challenge still lay ahead: writing code to interface with the pulseox.  The CodeBlue pulseox code was written in 2005 for TinyOS 1.0.  All of the low level UART and mote hardware interfaces have changed drastically since then, so the old code wouldn’t just work right out of the box.  I had seen plenty of posts on the CodeBlue mailing list about implementations for the pulseox in TinyOS 2.x, but nobody had bitten the bullet and actually written anything.

What I wanted was to be able to use the pulseox like a sensor on the MTS300/310 sensorboard: call a Pulse.read() or Oxygen.read() command and get back a uint16_t with pulse or blood oxygen saturation.  This is fairly straightforward since I had experience modifying the MTS310 sensorboard code to power on the sensors manually.  I created configurations PulseC and OxygenC to provide SplitControl and Read interfaces to power on the sensor and read, respectively.  I then wired PulseC and OxygenC to a PulseoxP, which functioned as an intermediary between the application and the low-level pulseox driver code.  Like in the original CodeBlue source, I created a BciC configuration and BciP implementation to communicate with the pulseox directly through the UART and return data back to PulseoxP.

The key changes between the CodeBlue TinyOS 1.0 code and my implementation are all found in BciP (or BCIM.nc in the original CodeBlue source).  Two issues come to mind.  First, setting the mote hardware pins is done differently in TinyOS 2.1.  Calls like TOSH_SET_PW0_PIN() are replaced by abstractions.  I had to wire MicaBusC.PW0 to the GeneralIO interface in BciC and then call GeneralIO.set() in BciP.

The second difference is with the UART.  TinyOS 1.0 uses the HPLUART interface for low level UART communication, but this has been replaced by Atm128Uart0C for the Atmel 1281 architecture.  The CodeBlue source code initializes the low level UART to its default state, turns it off, and then sets the hardware registers to the desired UART configuration so that the mote can communicate with the pulseox board.  After figuring out what the CodeBlue UART configuration code did, I can’t believe that you can actually write to the registers directly!  Imagine if you could do that with user-level code on a PC!  To enable transmissions and reception along with interrupts for the UART in TinyOS 1.x, you had to do the following:

// Enable tx/rx interrupts and tx/rx
outp(((1 << RXCIE) | (1 << TXCIE) | (1 << RXEN) | (1 << TXEN)) ,UCSR0B);

TinyOS 1.0 uses the outp() macro to set bits of a given register, but this macro does not exist in TinyOS 2.x.  Instead, the UART register bits are configured in a struct with fields for each bit in the register.  For the above example in TinyOS 2.1, the following union represents the control register in Atm128Uart.h:

/* UART Control Register */
typedef union {
struct Atm128_UCSRB_t {
uint8_t txb8 : 1; //!< UART Transmit Data Bit 8
uint8_t rxb8 : 1; //!< UART Receive Data Bit 8
uint8_t ucsz2 : 1; //!< UART Character Size (Bit 2)
uint8_t txen : 1; //!< UART Transmitter Enable
uint8_t rxen : 1; //!< UART Receiver Enable
uint8_t udrie : 1; //!< USART Data Register Enable
uint8_t txcie : 1; //!< UART TX Complete Interrupt Enable
uint8_t rxcie : 1; //!< UART RX Complete Interrupt Enable
} bits;
uint8_t flat;
} Atm128UartControl_t;

The flat uint8_t is a real slick way to convert all the elements in the struct to a single word, which can then be written to the register. Following the code that initializes the UART in tos/chips/atm128/HplAtm128UartP.nc, I was able to configure the UART to run with the pulseox board requirements: 4800 baud, double rate, transmission and reception interrupts enabled, no parity checking, 1 stop bit, and 8 bit word size.  So, with the previous example to enable transmissions and reception, you do the following in TinyOS 2.x:

Atm128UartControl_t ctrl;
ctrl.bits = (struct Atm128_UCSRB_t) {rxcie:1, txcie:1, rxen:1, txen:1};
UCSR0B = ctrl.flat; // ctrl.flat

I ran my concerns by the CodeBlue mailing list, which elicited a reply from Prof. Matt Welsh that I was headed in the right direction.  I finished my implementation, worked out some compile errors, and loaded the new pulseox and general data collection code onto a mote to see what would happen.  Almost never does my TinyOS code run correctly on the first try — usually I spend hours or days debugging, but this time it was magic.  A number jumped onto the screen in the data column of my PC Java application, which was connected wirelessly though a base station mote to the pulseox mote.  The sensor readings seemed reasonable for a heart rate, for jumping up and down and breathing hard made it go up and laying down and trying to breathe slowly made it slow down.

Pulse Oximeter Reading

I have made my code available here and any feedback, suggestions, or questions are encouraged.  To use it, place the pulseox directory into the tos/sensorboards directory in TinyOS 2.x.  In the makefile for your application, add the line “SENSORBOARD=pulseox”.

I recall a discussion in the locker room after cross country practice about a teammate I had never met.  I don’t recall his name, but this guy had graduated before I even got to college.  John, one of the well respected fifth year seniors said this guy wanted to go to NCAAs as part of the seven-man travel squad, but only “wanted to travel to the course, warm up with the team, and get a t-shirt.”  He did not want to actually run the race.  This guy never made the travel squad to NCAAs.  To him, and many others, it’s all about instant gratification without any of the work.  Running competitively isn’t like a movie where all the hard work is abstracted away and all that’s shown is the glorious win over the evil opponents.  To date, our team has qualified for every national meet since 1997, one of only five schools.   To do that takes considerable effort and years of training for hours every day.  You can’t just fast forward to the good parts.

The zeitgeist of today is marked by a lack of intrinsic motivation to undertake any long term efforts.  In Outliers, Malcolm Gladwell cites James Flynn’s work on how Asian students work harder and longer on problems than their American counterparts.  Given a tough math problem, most American students will work on it for only a short while before giving up.  This ethos carries over into other areas.  An article in the New York Times states that 95 percent of blogs are abandoned, many of which only have one post.  The torrents of traffic and commenters envisioned by these blog posters just doesn’t happen overnight.  They think blogging fame will come immediately, but it doesn’t.  It takes time to build a reader base.  More to the point, the blog also has to have content that people are willing to read.  I’ll be surprised if many people read this post or others like it concerning my opinions and everyday life, but most of my traffic comes from my software troubleshooting/debugging and knee microfracture posts.  Even in my little corner of the Internet, I have made gradual traffic gains over the months.  People just don’t swarm in overnight:

Apparently, the same is true for Twitter: most users either abandon their account after signing up or just make one post.  Again, the problem boils down to effort: few are willing to make the effort and post meaningful content at frequent intervals.  Followers just don’t appear because you signed up.  Like blogs, it isn’t just the frequency of posts, but the value of the content: I really don’t care what you ate for lunch today.  I especially don’t care that you got a front row seat at the Apple Developer’s Conference after waiting in line since 4 AM.  Most Twitter posts aren’t much better than spam.  To attract followers, the posts have to carry some value to those beyond a small circle of friends.

Everyone just wants the massive blog readership or the Twitter following, but couldn’t care less about the content required to generate such traffic.   Sometimes, when the desired outcome can’t be achieved with lackluster efforts, many try to lower the bar.  Currently, there’s an effort in Virginia Beach to relax the public school grading scale from 7 point to 10 point.  Parents think this will even the playing field with other school systems that have switched to a 10 point scale, but it’s really just lowering the standards.  Parents want their kid to get in to his or her college of choice and to do it by studying less.  Also along these lines, a state representive recently proposed that more in state students should be accepted to Virginia public universities because a constituent complained that the acceptance standards were too tough and he didn’t get in.  I’m guessing that this “constituent” was probably the representative’s kid.  What is the real secret to getting in to your college of choice?  It isn’t done by getting easier As or by pushing out extremely well qualified out of state students.  Work harder, and anything can happen.

It’s pretty bad that so many people give up when they realize some effort is involved.  It’s worse when people lower their standards of success when their current efforts are clearly lacking.  Believe it or not, there are even worse characters out there that will do anything to get instant gratification: cheaters.  Instead of working hard for ten months researching state-of-the-art, tweaking out a system design, implementing the design, testing the design against existing works, and finally writing and submitting a research paper, some people are willing to cheat.  A recent study reports that an astounding  2% of researchers fake their results.  In a similar instance, some colleges are willing to fudge the statistics to improve their rankings.  They play with class sizes and give peer institutions poor reviews to improve their standing.  Instead of improving the school in an honest way, taking the time to hire more and better qualified faculty, increasing employee pay, and attracting better students, Clemson faked its way up 16 places in U.S. News reviews.

What is the real solution to this lack of motivation?  How can more people motivate themselves to post regularly on their blog?  How can people stick with something and work hard enough to achieve just rewards?  Some slick researchers tried paying students for earning good grades.  This approach improved state test scores by nearly 40 percentage points.  Did money provide the motivation for these students to work harder and longer on their math problems and not give up?  Apparently.  Proponents of this system argue that the “real world” functions much in this way: perform better and get paid more.  But money can’t be added as an outcome in every scenario.  How many blogs or Twitter accounts are raking in the dough?  Almost zero, I would guess.  Instead, people need intrinsic motivation to produce results over the long term.  I don’t write this post because I envision piles of Internet surfers reading and commenting on this.  I do it because there’s satisfaction in organizing my thoughts and ideas and writing them down.  I don’t care that nobody else will read this, but if someone else finds it interesting, then more power to them.

Aside from writing these inane blog posts, it is intrinsic motivation that keeps me working on long research projects.  It’s what gets me up in the morning with the hope that I’ll be able to run normally again after knee surgery.  I run slow, go out every other day,  only go ten minutes, and feel terrible, but I know if I do it enough I’ll be able to run faster and longer.  By keeping at it and going one step at a time, things will get done.

I found that every time I called Read.read() for some of the sensors, that there would often be a delay in getting my data back with Read.readDone(). This delay was because each call to Read.read() would power on the sensor, requiring a warm-up time before a sample could be retrieved. While the warm-up time for the accelerometer is 17ms, the warm-up time for the light sensor is an excruciatingly long 1200ms! So, I would call Read.read() at 20ms intervals, but have to wait over a second to get data from the light sensor. When the data sample is returned at Read.readDone(), the sensor would power off again, thus requiring another warm-up the next time a sample is requested. Basically, the constant warm-up lag in the current TinyOS code prevents sampling at a reasonably fast rate using Read.

I also found that if I wished to get both axes of the accelerometer or magnetometer simultaneously, that only one axis would ever return data. The accelerometer, magnetometer, and light/photo sensors use the ArbitratedResource interface to block all other sensors that use the same resource when one sensor has a lock on the resource. If the x-axis accelerometer was sampling with Read.read(), it would have a lock on a UQ_ACCEL_RESOURCE identifier, preventing the y-axis from sampling simultaneously, since its resource is also identified by UQ_ACCEL_RESOURCE. I wasn’t the only one with these problems, as illustrated by this TinyOS mailing list post. The mailing list poster also points out that the ReadStream interface blocks data sampling for all sensors but the first one that calls it: if you try using ReadStream to get streaming data for the accelerometer x-axis and the magnetometer x-axis, the call to ReadStream.read() for the accelerometer would block the sampling of the magnetometer if it was called first. With ReadStream, all sensors use the same resource identifier, so when one is sampling, it has the lock, and all others must wait. The resource arbitration effectively prevents multiple sensors from sampling data simultaneously using ReadStream.

This automated power control for Read as well as the blocking for Read and ReadStream really limits the functionality of the sensorboard. Initially, I thought it was a hardware constraint. You would think that since the board has all those sensors on it, the manufacturers would have designed it such that you can use all the sensors at the same time. It turns out, that it isn’t a hardware problem — it’s just that the MTS300/310 sensorboard code is written so you can only effectively use one sensor at a time. I managed to change this by modifiying the behavior of the Read.read() of every MTS sensor.

The current TinyOS code uses SplitControlPowerManagerC to power on the sensor when you call Read.read(). Read.read() triggers the power manager to call the sensor’s SplitControl interface. Supposedly, when Read.readDone() is signaled and the sensor data is ready, the power manager will keep the sensor powered on for some amount of time in case the sensor is needed again — this is from the comments in PowerManagerP.nc. However, from my testing, there is no evidence that the sensor stays on after Read.readDone() is signaled. The warm-up routine starts all over again the next time Read.read() is called. It’s possible that 20ms is too much time between samples, but it appears from the power manager code that the sensor is turned off immediately if no resource requests for that sensor are pending. Currently, I can’t find anywhere in the MTS310 sensorboard code or in the power manager code where some kind of backoff timer is set before powering down the sensor.

To that end, I eliminated this automated power control through the power manager. I altered each sensor’s interface in the mts300 code library so that each sensor provided a SplitControl interface. This now allows me to manually power on each sensor I want to use before I start sampling. I then have a timer call Read.read() at regular intervals for each sensor I want, which returns the data with Read.readDone(). When I’m done sampling, I can turn the sensors off.

The current code is more a less a hack and has a weird side effect. For example, since the x and y-axis accelerometers use the same AccelP module with the same SplitControl power interface, only one accelerometer has to call SplitControl.start() to turn the sensor on. The same goes for the magnetometer and the light/photo sensors, as well as for calling SplitControl.stop() to power down the sensors. Otherwise, the warm-up/power on sequence is triggered twice for the same sensor if you want to use both axes of the accelerometer or magnetometer, or wish to use both light and temperature sensors. Edit: this issue has been fixed in the code.  Calling SplitControl.start() for both axes of the accelerometer/magnetometer will only run the power on sequence once, but both calls will return SplitControl.startDone().  The same applies for SplitControl.stop().

The modified sensorboard code can be downloaded here, which is a zipped directory of all the mts300 sensor code, but changed to mts310. Just unzip it into the tos/sensorboards directory. The configurations AccelXC, AccelYC, MagXC, MagYC, MicC, PhotoC, and TempC have all been modified to provide the SplitControl interface, so for example you can call AccelXC.start() to power on the accelerometer, then AccelXC.read() to get data, and then AccelXC.stop() to power the accelerometer off. I’ve used this extensively with the accelerometers, magnetometers, acoustic, and light sensors and it seems to work without any issues.

As I see it, the ultimate goal in the computer science community is to provide systems that improve our lives without us even being aware of it. Stuff should just happen in the background that we don’t even know about to provide drastic improvements in general areas like productivity, entertainment, and communication. All the background noise should be filtered out by these hidden systems so that we only see things that are important to us. For now, it seems, nothing is being filtered out and we are subjected to an increasing amount of information, almost all of which we really don’t care about. For example, this morning I searched Google for “mp3 players” (as in the physical devices) and only got hits for software programs. Problems like this shouldn’t happen, and I shouldn’t have to type in some weird query to specifically exclude certain results from my search. Some serious work has to be done to limit the scope of what we see to only the things that matter, and do it in such a way that isn’t annoying. Basically, operating systems and software should just work and not require any hacks to get solutions we want.

The first issue that comes to mind is with today’s operating systems. Gigabytes of patches and updates are released each month and harass the living daylights out of the end users to install them. This is one of the best examples of the Nag Factor. An operating system should not endlessly nag the user about installing updates and allowing administrative privileges. Ideally, the user shouldn’t even be aware that he or she is using a computer at all. Updates should be automatic and occur in the background without the user even knowing. Nothing is more annoying than to be deep into writing a paper or watching a movie when up comes a nag balloon demanding that some updates be installed and the machine rebooted.

Windows is far and away the worst when it comes to the nag factor. I’m almost completely off Windows at this point, with the exception that I use a partition on my laptop for my USB TV tuner, which unfortunately doesn’t have Linux drivers. It seems every time I start up the machine, about five nag balloons pop up telling me what wireless network I’ve connected to. About once a week another torrent of nag balloons pop up telling me to install software updates. When I finally install the updates, Windows forcefully reboots my machine. Nothing, I mean absolutely nothing, should ever forcefully reboot your machine. It’s a complete disruption of anything resembling the mantra of ubiquitous computing. A professor I had for a software engineering class once told me that it takes about eight minutes for someone to become completely engaged in a task. When some moron at Microsoft thinks it’s a good time to make your machine reboot, that’s about five minutes of lost productivity due to the reboot, and another eight to get back to where you were. Even Bill Gates complains about the forced reboots in Windows. Since I’ve never used Vista, I’ve heard another annoying “feature” is the User Account Control system, which ceaselessly has you type in your administrative password for stuff as simple as connecting to a wireless network.

Next up is OS X. Two years ago, I started the shift away from Windows with a Macbook. My Windows desktop began rusting from disuse almost immediately. Unfortunately, OS X suffers from the update nag almost as badly as Windows. Nearly every update is hundreds of megabytes and requires a reboot. iTunes updates even require reboots — what were they thinking? And when you install the stuff, it takes forever. Sometimes on an OS X update, my machine has rebooted two or three times over about ten minutes before the login screen comes up again. The updates first make their way to you through the extremely aggravating dock icon jumping out at you. While the dock is a good feature, the jumping icons are not. I can’t describe how irritating it is to be doing something and have a dock icon start leaping out into the center of my vision, ceaselessly pushing my buttons until I deal with it. There is probably a way to disable the icon jumping, but I’ve moved on from OS X, so it doesn’t matter at this point. UAC is also present in OS X but the designers did a decent job of only prompting you when changing administrative settings or installing software.

For the past year, I’ve almost exclusively used Ubuntu Linux for all of my computing. Finally, a group of developers has the right idea. It works almost seamlessly. An operating system should do its best to get out of the way and let the user do what he or she wants. Ubuntu is really close to doing this. The package manager is excellent — you can install anything under the sun (for free) and it updates automatically. You can’t even do this with the Mac by default, unless you install something like DarwinPorts, and even that is a real hassle to set up. The downside is that since every program you install is controlled by the package manager, there are frequent updates that require your authorization to install. Nearly every day something has a patch, but the package manager does its best to be minimally invasive. Nag balloons are infrequent, and a small icon appears in the task bar indicating that an update is available. Reboots are almost never required except for things that affect the kernel and nothing is ever forced on you. For now, I’m extremely satisfied with my Linux experience and will probably not switch back to Windows or Mac unless some serious revamping occurs.

The nag factor isn’t present in operating systems alone. The devices that are beginning to make ubiquitous computing a reality are providing irritations of their own. Whenever I miss a call, get a voicemail, or receive a text message, my cell phone beeps and hums to no end until I touch the screen acknowledging its nags. I’ve had two phones, and they both did this. Neither has the option to turn it off. I can check manually to see if anything came in while I was away from my phone and would prefer to do so instead of being constantly annoyed. I’ve also noticed that late model cars now beep at you if you start the engine and have your seatbelt off. Apparently, this is mandated by the federal government, but it’s just another irritating nag. Some cars will nag at you after the mileage counter gets beyond a certain amount since your last service.

It isn’t just the nagging that’s a problem, though. Some poor design decisions really limit the usability of computing systems and ubiquitous computing devices. The worst of this is proprietary software and hardware, with Apple really standing out as the worst culprit. The iPod that’s starting to die on me has a proprietary USB jack to plug it into my computer. What makes me mad is that it didn’t come with a wall plug to charge it — I’ve got to use the proprietary adapter to charge it via USB or for over $40 for a wall adapter. Since I don’t need to sync my iPod every day and would like to be able to travel with it without bringing my computer, a wall plug would be great. Thanks to the wall plug adapter scam, I don’t think I’ll be getting another iPod if I can help it. Apple’s computers also make use of proprietary headphone jacks and video outputs such as mini-DVI and mini-DisplayPort. I had to fork over $20 to get a mini-DVI to DVI adapter so I could use an external monitor with my Macbook. Universal hardware standards would make ubiquitous computing much more of a reality, with devices seamlessly integrating with each other and providing minimal headaches to the end user.

With respect to proprietary software, the iPod/iTunes combination also takes the cake. When I first got my iPod, I was using Windows, and installed iTunes on Windows to keep my music and iPod in order. After I got my Mac, I tried plugging the iPod into the Mac and using the Mac to keep everything synced. Did this work? Of course not. iTunes on the Mac whined that my iPod was formatted for Windows and that it couldn’t write anything to it unless it was reformatted. I don’t see why the geniuses at Apple could have written some drivers so that the iPod’s file system could be accessed from any operating system. It all seems to be about control. Downloading songs from iTunes only allows you to have those songs installed on three machines simultaneously and you can only load them onto an iPod in a proprietary format.

Cell phones are another example of this walled garden approach. You not only pay for the access to a cell network, but you have to get a proprietary operating system running on a proprietary phone to go along with it. You can’t just build your own cell phone out of spare parts, install your own operating system, and expect to connect to Verizon’s network even if you’ve paid for it. Google’s Android seems to be a step forward to breaking down this situation by permitting custom applications, but there’s a long way to go. Without all this proprietary junk to get in the way, you could see some seriously interesting applications, such as P2P file sharing on cell networks, refinement of video and text messaging, and the eventual integration of portable gaming, media, and communication into one device (the iPhone still sucks). For now, I’ve got to carry around my laptop for web browsing and programming, my cell phone for telephone calls, my iPod for music, and my PSP for gaming. Oh, and maybe a watch to tell time.

Finally, coming back to my dying iPod, battery technology needs significant improvements in order to further the goals of ubiquitous computing. Reducing I/O and computational complexity on the software side can only help but so much. The typical Ni-Cd battery, regardless of the device, lasts about two to three years and only runs for a few hours under full load. This is crap. Until batteries last for a week under full load and hold a full charge for nearly ten years, we’re just going to be throwing away perfectly good equipment. My iPod, which is perfectly fine with the exception of the battery, could last an indefinite amount of time. It seems really wasteful to toss cell phones and other mobile devices every few years just because a battery died. Reduced reliance on proprietary hardware and software could help this problem as well, for parts could be easily interchanged or upgraded if new features become available.

If the tech industry would focus on reducing the nag factor and increasing the openness of design standards, the shift to ubiquitous computing could be faster and more seamless. Until then, we’ve got to deal with the endless OS nag balloons, proprietary devices, and terrible battery life.

There is a more heavyweight solution, if you like Eclipse.  Since I’ve been using Subclipse with Eclipse on several machines to keep all my code in sync, I’ve found Eclipse to be pretty useful.  A TinyOS 2.x Eclipse plugin is available on this site that provides syntax highlighting and it appears as though it will compile and install source code as well (though I haven’t tried that part).

2/21/2009: Since I’m on the topic of Eclipse, I’ve noticed that the Ubuntu repository Eclipse version is 3.2, but 3.4 is available from the Eclipse website.  Following this guide, it seems that you can override the /usr/eclipse directory with the new version if you want to upgrade.  Plugins will have to be reinstalled, though.