Within the past few days, my news feed has been jammed with these “numbers” posts.  For the most part, it’s been people who I haven’t seen or talked to in years posting a status update with a number followed by a random out of context comment that makes no sense to me.  It’s been getting so bad that one of my Facebook friends posted that he would defriend anyone that posted another “numbers” status update.  While these people aren’t trying to sell me Viagra, the effect is the same as email spam: annoyance and frustration.

It’s no surprise that the top reason for defriending is “frequent, unimportant posts.”  Others, as well as myself, are getting frustrated with junk like these “numbers” posts and are on the brink of defriending the perpetrators.  To solve this, I propose FeedMod, a Facebook news feed moderation system to remove the garbage and push the good stuff to the top.

Disclaimer

I have absolutely zero experience with the Facebook API, so I have no idea how much of this is possible.  We’ll see.

How it works

My proposal is to borrow from the Slashdot moderation system.  Facebook already has a “like” button, but it’s inconclusive that by clicking it, similar posts will be given priority in the news feed.  There is also an “x” for each post, but clicking this seems heavy-handed, since it appears to blot out most posts from that particular friend.  Instead, FeedMod participants will moderate each post with a positive, neutral, or negative descriptor.  The results of this moderation is to flush out the good posts and hide the bad ones.

Unlike the Slashdot system, every news feed post can always be moderated by a FeedMod user.  With Slashdot, the goal is to have publicly acceptable posts float to the top, hence the need for randomly selected moderators to avoid gaming the system.  With FeedMod, however, the goal is to have posts acceptable to individual users float to the top, so users should be able to moderate everything in order to provide as much training information as possible.  Perhaps later the moderation can extend across groups of friends so that certain Facebook users can be recognized as having posts liked or disliked by all of their friends.

Label each post as good, bad, or neutral

I would keep all the positive Slashdot post descriptors: informative, insightful, interesting, and funny.  I would keep one neutral descriptor, such as “normal” or “neutral.”  Also, I would modify the negative descriptors from what is used on Slashdot so that they are more appropriate for social networking and individual preferences: out of context, spam, unintelligible, and troll.  Most news feed posts that annoy me either fall into the “unintelligible” or “out of context” categories: posts that make no sense due to poor writing skills or lack of background information since I don’t live every minute of my life with the poster.  Stuff like the “numbers” posts would fall into the “spam” category and posts from friends looking to incite others (usually politics) would get labeled “troll.”

Customized News Feed

As a FeedMod user labels each news feed post with a descriptor, the news feed becomes customized to the user’s preferences.  This is the tricky part, because I’m not sure if the Facebook API will allow me to rip out the text of each post and store it in a database.  If I’m able to do that, I can try to model a user’s feed preferences based on the friends they mod as mostly positive or negative and the likelihood that a new post from a particular friend will be acceptable.  I could go a step further and find keywords or topics that are found in good and bad posts, allowing new posts to be shown or hidden in the feed based on their content.

If all else fails, defriend

I should definitely be able to rank a user’s friends by the number of positive, neutral, and negative posts.  That way, after a few weeks of modding posts in the news feed, a user can have a top 5 and bottom 5 list of the most liked and most offensive friends.  Then, the user can just defriend those bottom 5 and see an increase in the news feed quality.  There can also be rankings by each specific positive or negative descriptor as well as ranking by post volume.

What’s Next?

When time permits, I’ll try to figure out what the Facebook API is capable of and hopefully be able to attach moderation descriptors to each news feed post.  With that, I’ll be able to find the friends whose posts I like the most as well as the least.  Learning preferences will be more difficult, especially if the API has limitations on what can be accessed in a user’s news feed.  Why Facebook hasn’t already implemented a better news feed moderation system is beyond me.  I’m sure they’ve at least considered it.

With email nearly as old as the internet, the protocol still in use today assumes that: 1) All users trust each other, and 2) All users have a moderate level of skill to send and receive email properly.  The failure of the first assumption has led to the high levels of spam and phishing emails we see today.  There is no trust: how does anyone know that a link supposedly send by a friend isn’t a botnet client?  The failure of the second assumption is just as bad: how many jobs have been lost due to a hasty “reply all” click?  The remainder of this post will focus on the second assumption: email misuse.

Mailing List Misuse

The timing of Facebook’s email announcement coincided with an incident that really demonstrates that it’s well past time for email to die.  I have subscribed to a fair number of mailing lists throughout the past 15 years or so I’ve been using email.  As per Wikipedia, electronic mailing lists fall into two categories: 1) Discussion lists, and 2) Announcement lists.  Discussion lists, such as the TinyOS programming help mailing list, allow all subscribers to send questions to everyone else in the list.  Someone poses a question in the email, puts the mailing list address in the “to” header, and once sent, all other subscribers get the email.  Anyone with an answer “replies all” to the list so that everyone can benefit from the discussion.

Announcement lists, on the other hand, are only a one-way broadcast.  Only a single owner is permitted to send announcements to all subscribers on the list with the recipients unable to reply to all.  That’s the idea, anyway.

In September, I joined an alumni mailing list which I would estimate has at least several hundred subscribers.  The list owner sent out regular updates at an interval of roughly once per two weeks, as illustrated in the figure below.  However, following the most recent announcement, chaos ensued.  On September 15th (see figure), a subscriber learned that he could “reply all” to the list and not only email the list owner, but all of the other subscribers as well.  For whatever reason, the announcement list was set up like a discussion list, allowing any subscriber to reply.  It only got worse from there.

Once one subscriber hit "Reply All", the rest is history...

Soon, a torrent of emails followed in the steps of the first subscriber as one person after another typed up a response and hit “reply all.”  Being an alumni list, the discussion circulated among a group of individuals of about the same class year, discussing subjects that made no sense to anyone else.  The responses quickly got out of hand: through the afternoon of September 15th, the sending rate soared to well past 1 email per minute.

After the initial rush of random discussion, complaints ensued.

Following a mad surge of random discussion on the 15th and another resurgence on the afternoon of the 16th, subscribers began to email the list complaining about the onslaught.  One after another, again surging past the rate of 1 email per minute, subscribers demanded that they be unsubscribed and that the discussion be taken to a message board.  Finally, the message was heard: everything died down and stopped completely by the evening of the 16th.

So what went wrong?  First, the list owner should have ensured that he was the only one able to send emails to the list.  Second, a significant number of subscribers emailed the list in an attempt to unsubscribe instead of emailing the list owner.  Both mishaps plus the breach of protocol for announcement lists made things quite a mess in only a few hours.

Some other interesting statistics can be computed in the aftermath.  Since the list’s inception, about 10% of the total volume can be attributed to announcements, 50% for misuse/discussion, and 40% for complaints about the discussion.  Next, we show the age distribution of senders:

The misuse is confined to the 45+ age group.

Since this is an alumni list, I was able to determine the age of just about every sender within two or three years, however, beyond some quick Googling, about 2% of the senders have an undetermined age.  The above figure shows that those who abused the mailing list for discussion are all older than 45.  Conversely, there is a roughly even distribution of age for those complaining.  There is also slightly lower percentage of users under 45.  From the figure, we can conclude that the younger generations are savvy enough to avoid either: 1) Misusing the announcement list as a discussion list, or 2) Sending the list an unsubscribe email instead of the owner.

Another interesting fact is that 37% of all senders used a business email address to reply to the list.  37% of senders used their business email for personal reasons!  That’s insane.  Another 9% had nasty hundred word “disclaimer” signatures at the end of their messages.  Stuff like: “THIS IS A LEGALLY PRIVILEGED AND CONFIDENTIAL COMMUNICATION THAT IS INTENDED TO BE VIEWED ONLY BY THE INTENDED RECIPIENT…ANY DISSEMINATION, DISTRIBUTION, OR COPYING OF THIS TRANSMISSION IS STRICTLY PROHIBITED.”  I think the distribution and copying prohibition went out the window the minute they hit “reply all.”  It’s a wonder more people don’t get busted for stuff they put in emails.

In conclusion, this case study demonstrates exactly why email ought to be abandoned.  There are too many avenues for abuse, misuse, and unintended consequences.  It would be nice to see Facebook come up with something appropriate for today’s internet.

When using python (tossim) to test the application code written using nesC, how did you make nesC code and python dependent on each other or how did you control the nesC code from python? Did you use swig to export the interfaces from C to python or ran the application code directly on nesC by hard-coding them thus making nesC and python independent?

The TinyOS tutorial for TOSSIM does a pretty good job of explaining this.  The idea is to write your TinyOS application code as if for a real mote.  Then you can compile it for TOSSIM:

$ make micaz sim

This will automatically create the wrappers needed for your TinyOS program to interact with Python.  You don’t need to do anything with SWIG yourself, the TinyOS makefile does this all for you.

My goal here is to compute throughput, packet delivery ratio, end-to-end delay for an arbitrary number of nodes say 10 to 50.

You can access nesC variables directly from a Python script that runs your simulation.  You can easily access a sequence number variable or a variable that tracks the number of retransmissions of a specific node in the simulation.  Again, the TinyOS TOSSIM tutorial explains this in greater detail, but in your Python script you can have something like:

m = t.getNode(0)
v = m.getVariable("MyAppC.seq")

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 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.

To solve it, you can do the same thing I did: disassemble the binary and use the debugger.  Be sure to set a breakpoint so that you won’t set off the bomb accidentally.  As long as you’ve got that breakpoint set, you’ll never lose any points.  Step through the assembly code line by line and try to figure out how the input is manipulated.

But now, it’s almost worse. I started working on my current project in September, right after my knee surgery. It’s been going for nine months and now I am finally cramming all of those nine months into ten pages or less, double column.

To put this in perspective for an undergrad: take all the papers, all the projects, all the homework assignments, and all the exams, tests, and quizzes in the last two semesters and make them all due next week. That is the weight of what I am working on. It nags at me every day that I have been working for so long and have nothing to show for it. I think about it in bed before I go to sleep, I think about it when I wake up, I think about it when I’m in the shower, and I think about it when I’m on the bike. As an undergrad and even for the first part of grad school, I got closure incrementally: with periodic assignments and tests and at the finish of each semester when classes end. Closure is now when I get a paper out, and the time span for that seems indefinite.

My first project and paper was faster — it took a semester and a summer. However, I’m still dealing with that project now — I’m going to present it at SECON and when I do, it will almost be a year since the first version of the paper went out.

It seems most undergrads treat papers lightly: “Oh, I can crank out a ten page paper in a few hours and still get an A…” I was the same way — it was spit something out as fast as possible to get it over with, but put enough effort into it to get a decent grade. Now, papers are everything. The paper is how everyone else sees your work. I may have spent the past nine months creating something that could have huge implications for the future of wireless sensor networks, but nobody but my adviser would know about it unless I tell them in a paper. The reviewers will lay the smack down on you if you try to whip out a paper in a matter of hours. Yesterday, I spent six hours writing and got out about five paragraphs. They were five critical paragraphs about the core of what I did, and they had better be comprehensive and understandable from the perspective of an outsider.

I find it hard to tell the story of my project, but I think the difficulty is from inexperience. There are key things that reviewers look for that I must give special attention in addressing. Because of this, there is a pretty rigid way to write a research paper, but even then I find it difficult. It is hard to convey specific algorithmic details, yet be concise and easy to understand. I have to remember the main selling points of my work and refer back to them throughout the paper. For these projects, I find the initial problem discovery, solution design, and implementation to be interesting and sometimes even fun. Enough experience programming and thinking about solutions to problems has helped with that, but I haven’t done much writing.

With time, I imagine writing will get easier. I will know exactly what to do. With my current paper, I’m almost there. I’m almost to the point where I feel good about what I have written and know that everything will turn out okay. I just have to keep working and get it done. Then there will be some closure.