While Facebook provides a “like” button to indicate approval of news feed posts, there is no indication that this feature is used to filter news feed content.  Facebook does provide an option to block news feed posts of designated friends, but this is a very coarse grained filter.  More recently, Facebook presented an interesting analysis of news feed posts.  This study identifies post topics that are more likely to be “liked” or commented on by friends as well as identifying post topics that are correlated with high friend  counts.  While the Facebook study analyzes post content, it only compares against metrics inherent to Facebook itself, such as “likes” per post, number of comments per post, age of posters, and friend counts.  The study neither attempts to quantify the news feed topic preferences of Facebook users, nor does it attempt to identify a Facebook user’s best or worst friends based on friends’ news feed posts.

Design

As previously mentioned, the main idea is for each FeedMod user to moderate each news feed post in a manner similar to Slashdot post moderations.  Each news feed post is assigned a moderation which consists of an integer value score and descriptor string.  For this experiment, I chose the following moderations:

Value	Descriptor	Examples
-2	Troll	Rants or politically charged arguments; I really can't stand these, hence the -2
-1	Spam	Advertisements, such as requests to attend an event, donate money, or to come to a friend's place of business to buy something
-1	Redundant	Endless duplicate announcements, typically on holidays and birthdays
-1	Indifferent	Stuff I really don't care about, such as random song lyrics or sports posts about teams that I don't follow
-1	Unintelligible	Something posted out of context, usually by someone with whom I'm out of touch
0	Normal	I assign my posts to this, otherwise I use it rarely
+1	Funny	Self explanatory, but I found myself only using it when I was about to fall out of my chair laughing
+1	Insightful	Anything that gives insight into the highlights of a friend's life or a well formed argument on a topic
+1	Informative	Usually updates on what someone is doing
+1	Inquisitive	Someone posing a question to his or her friends
+2	Interesting	Usually news articles or a post about something I hadn't heard of or thought about before (these posts are the best, hence the +2)

By moderating the status updates of all of my Facebook friends, I am then able to assign a score to each friend based on those moderations.  I can even moderate status update comments made by friends and non-friends alike.  The score, similar to Slashdot’s “karma,” is created by summing the moderation values for all of a friend’s posts.  In this way, I can see the balance of how positive or negative a friend’s posts tend to be.  The advantage of this method is that friends with a large number of good or bad posts will stick out.

Implementation and Facebook API

My original idea was to use the Facebook API to modify the news feed and allow me to moderate friends’ posts.  A month ago when I started this, I had no experience with the Facebook API and did not know if it would even allow me to do such a thing.  While I did achieve what I wanted in being able to moderate friends’ posts, I can say conclusively that the Facebook API is seriously lacking.  I have two major issues with the API: 1) an inability to customize the Facebook website, forcing developers to reinvent the wheel for even the smallest applications, and 2) limited access to information easily accessed on the main Facebook website.

What I really wanted to do was to be able to modify the existing Facebook news feed and insert a moderation select list next to each status update.  When a FeedMod user selected a moderation, the post-moderation pair would be stored in a database.  Unfortunately, Facebook does not allow developers to modify any portion of the Facebook website, including the news feed.  It would be much easier if Facebook allowed this since I wouldn’t have to recreate the entire news feed.  This lack of customization is a serious barrier to developers who have an idea for a simple application that makes use of the existing Facebook website.

The Facebook API does, however, allow you to query status updates and friend information for use on your own website.  What I learned was that apps within Facebook are actually remote websites running within an iframe on the main Facebook website.  Unfortunately, Facebook limits the information you can get: news feed items are restricted to status updates, links, videos, and photos — you cannot retrieve time ordered taggings, newly added friends, profile picture updates, and likes, among other things.

Interface

While I found the Facebook API disappointing, I was able to recreate the Facebook news feed on my own webserver, using the Facebook PHP toolkit.  Finally, with a database backend to store moderations, I was able to produce a customized news feed with the ability to moderate friends’ posts:

News Feed with Moderation Select Lists

To the right of each status update, I included a select list to moderate the post.  I also display the current moderation total for the friend, the friend’s moderated post count, and the percentile rank out of all friends (the friend with the most negative moderation total is 0%, the most positive is 100%).  This way, at a quick glance it is easy to see how many good or bad posts a friend has made to date.

I also created a statistics page, which ranks friends by the number of posts as well as lists of the top ten best and worst friends based on their moderation totals.  I also breakdown the moderation total and display the leaders of each moderation attribute (for example, who has the most “spam” posts).

Evaluation

After finishing the implementation, I then moderated posts for a month and now present an analysis of the results.  During a one month period, I moderated over 2,000 posts with 250 individual posters.  Some other interesting tidbits:

• 67% of my friends posted at least once within this one month period
• 64% of all moderated posters were friends; the remaining are non-friends commenting on a friend’s post
• 93% of all moderated posts were made by friends

Here is a breakdown of all moderated posts by their assigned attributes:

Moderation attributes by percentage of all moderated posts.

From the figure, a clear majority of posts are positive, while 35% are negative.  Out of all negative posts, the “indifferent” and “unintelligible” categories are used the most.  On the whole, I find most posts that I don’t like to be something I don’t care much about (and don’t want to read) or something that I don’t understand (usually it’s something taken out of context), hence the pervasiveness of the “indifferent” and “unintelligible” categories.  The “informative” category dominates the positive posts, followed by “insightful” and “interesting.”  My experience is that a significant number of posts (almost 40% to be exact) are status updates announcing what a particular friend is doing.  While most of these are mundane, I don’t really find them to be bothersome, hence the positive score.

Next, we look at how many posts each Facebook friend created during my one month evaluation:

Most friends post very little, but a few post all the time.

This figure shows the number of posts made by each friend that posted at least once.  A little less than 40% of my friends posted once, while about 3% posted more than 40 times in the past month.  One friend posted almost 120 times, or roughly four times per day!  Clearly, my news feed is dominated by posts from the same handful of friends.

Next, we look at the distribution of moderation scores across all of my Facebook friends:

Most of my friends have slightly positive moderation scores.

This figure shows that most of my Facebook friends (the ones that posted at least once) have a slightly positive moderation total. Since most of my friends do not post very much, the lack of extreme scores makes sense.  A small number of friends have very bad or very good scores — 3% have have a total less than -6 and another 3% have a total score greater than +20.  Those 3% that have the worst scores clearly stand out from the majority of my friends and are definitely good candidates for defriending.  Conversely, the top 3% go a long way in keeping my news feed enjoyable.

Lastly, we look at both post count and moderation total:

Friends that post more tend to be more positive, but there are some outliers.

Here, we see the quantity and quality of posts made by each Facebook friend.  Some friends have identical (post count, moderation total) values, hence the z-axis indicating the number of overlapping friends.  Like the previous two figures, this shows that most friends have slightly positive moderation totals and low post counts.  It also appears as though friends with higher post counts tend to be more positive.  However, there are some friends that buck the trend and have very negative scores for relatively high post counts (as identified previously, these are the ones that should be defriended).

Conclusions and Future Work

After struggling with the limitations of the Facebook API, I was able to implement a moderation system for Facebook news feed posts. This moderation system quantifies the contributions of each friend to the news feed and clearly identifies the friends with very good and very bad posts.  Using this system, it is possible to filter the news feed based on friends’ moderation scores as well as filter the news feed based on previous moderation of similar content.  It is also possible to extend the moderation system across a user’s social network, identifying friends whose posts are well liked by everyone.

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.

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.

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.

I think I’ve got about 10,000 lines that I’ve written for this over the past few months, which easily surpasses anything I’ve worked on before.  Nearly every week I’ve made significant changes to existing code and added in a lot of new stuff.  Something of this size in a constant state of change is a new challenge to me.

Consequently, I’ve taken a lot of steps to keep everything organized since I can’t do it in my head.  Since the code is mostly in Java, I’ve done my best to take advantage of its object oriented nature.  I try to keep things as loosely coupled as possible so that when I’ve got to make some modifications, it doesn’t screw everything.  I’ve made use of Java packages to group stuff together that has similar functions.  On top of all that, I’ve put the project into a Subversion repository so I can always go back to old stuff and so that I can work on it from multiple machines without it being a huge headache.

Of course, this is standard procedure for any programmer, but until now it’s never been absolutely necessary for any projects I’ve worked on alone.  During my internships, I had worked on stuff that was in the tens of thousands of lines, but it had been contributed to by other people.  Good programming practices made sense since other people would be working with my code and vice versa.  With what I’m working on now, it’s almost as if some of the stuff was written by someone else.  I’ll come across a method that I wrote two months ago and not remember much of how it worked.  I feel like a one man programming team.  I recall an interview of Bjarne Stroustrup that complained about grad students that would work on their own projects and write terrible code, not expecting that later on it would be needed for another project or possibly released to others.  I’d rather not fall into that trap since the stuff I’m working on now will likely see plenty of use in the future.

Increased comprehensiveness is one reason they say that Extreme Programming is so valuable — having someone else there with you really helps in making something that not only works, but is built in such a way that everyone can understand it.  Some people, including myself, can often write something that is almost completely unintelligible to others.  Knowing this is one reason I like to avoid cramming several actions into one line, for which I’ve gotten grief from others about being “verbose”.  I’d rather be verbose, but understandable than concise ambiguous.  I’ve never understood why people brag about writing a program in as few lines as possible, usually in some loosely-typed scripting language.  For part of this project, I had to use someone else’s MATLAB script to convert some trace data.  Of course, they crammed the conversion code into about fifteen lines that took me forever to figure out what it did (partly because I’ve never used MATLAB).  Not wanting to revisit that, I translated the code into Java in a more drawn out format so it would integrate well with the rest of my project.

I’m sure there are plenty of things I could do to make my code more better than it is now, but it’s hard to improve when there isn’t someone to give you feedback.  I can learn from my successes and mistakes from previous projects when working on my current project, however.  It seems as if most good programming practices don’t matter so much when the code size is small, but when a threshold is crossed, they seem to go from irrelevant to absolutely necessary.

First, the mouse.  I have a Razer Copperhead USB mouse that’s been great for years and when I first booted after the installation, it didn’t work.  The lights came on, but I couldn’t move it.  If I unplugged it and plugged it back in, it worked fine.  This would happen every time I rebooted the machine: no movement, unplug, plug back in.  After some digging around, I found the problem was that the mouse firmware had to be upgraded.  Of course, Razer only has the update software for Windows, so after some screwing around with that, I rebooted with the Linux machine and it worked fine without having to unplug the mouse.

Second, the dual head support for my ATI video card was lacking after the initial install, just mirroring my primary monitor onto the other.  I was able to fix this by installing the proprietary ATI drivers and using the ATI Catalyst Control Center to “merge” both screens into one.  Of course, this didn’t entirely fix the problem since every time I rebooted, the mirroring came back.  I finally found out that after I set the displays correctly in the ATI Control Center that I had to open up the Ubuntu Display Settings panel and hit “Apply”.

Both of these problems were really annoying, kept me searching and frustrated for hours, and have rather quirky solutions.  While I really like Linux, stuff like this doesn’t seem to happen as much with Mac or Windows.  However, community support is pretty good so after some extensive research I was finally able to find others with my problems that had found solutions.

Now everything seems to be working well, except that the stand for my monitor arrived bent.  It’s only a couple millimeters out of shape and the box it came in seemed undamaged, so I’m not sure what happened.  It’s bad enough that when I type sometimes the monitor wobbles.  It’s something I could probably live with, but the wobbling is annoying and I paid for a new product (not refurbished) so I don’t feel like letting it go.  So, I spent two hours with phone tree hell HP tech support about returning it and then filed an RMA request from the online vendor.  It would be best if I could just replace the stand since the monitor is fine — there’s only one stuck pixel.  Shipping the whole thing back is going to be expensive if the RMA is approved.  I guess the question is if the bent stand is worth another $30.

I still haven’t gotten to the Xbox yet because of all this (and some other annoying legwork type stuff for a research proposal that is due this week).  It also turns out that I got the wrong RCA to mini-stereo adapter and will have to try to exchange that so I can plug in the Xbox sound to the line in on my PC.  The whole thing is kind of funny because part of the reason I went with an Xbox was to avoid dealing with putting together a new system and troubleshooting the whole thing when a bunch of stuff doesn’t work.  Instead, I got more than I bargained for.