Posts Tagged development
Freedom or Stability?
Windows and Mac users can download and install the newest Firefox version with a couple of mouse clicks. With Ubuntu Linux, however, no Firefox 3.6 is available in the Canonical package repository. Even worse, none of the developers plan to add any new Firefox versions to the repository until the next Ubuntu release. So, I attempted to install precompiled versions from the Mozilla website and the Ubuntu Firefox development build repository, but both installs really messed up the fonts, making them blurry and hard to read.
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.
BCI Pulse Oximeter in TinyOS 2.1
Posted by Matt in development on June 15, 2009
After days of getting lost in TinyOS 1.1 and 2.1 low level hardware abstractions, the Harvard design BCI pulse oximeter now works in TinyOS 2.1.
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”.
Get Rich Quick: It’s too good to be true
After nearly ten months of work, I finally submitted a paper for review. At the end of next week, I go to Rome to give a conference presentation on work I had started over a year and a half ago. Research, like many things, takes a lot of time and effort to reach a milestone. There are no shortcuts to accomplishment, no matter what some sleazy TV salesman will tell you. People set out with dreams of instant gratification only to face the reality that only time and effort will provide them with reward. Instead of foraging on, they give up. In some cases, when faced with the prospect of immense effort for a small chance of success, others will just cheat. Why is this? What can be changed to provide motivation for long term efforts?
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.
MTS300/310 Sensorboard: Sampling multiple sensors simultaneously
Posted by Matt in development on May 14, 2009
My current project involves sampling data with the Crossbow Iris and MTS310 sensorboard. I wish to sample data at regular intervals, say 20ms, using all available modalities on the MTS310: x and y-axis accelerometer, x and y-axis magnetometer, light, temperature, and acoustic. Every 20ms, a timer fires and collects data samples from each sensor using the Read interface. As it turns out, the current TinyOS 2.x code for the MTS300/310 does not allow this.
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.
Ubiquitous Computing: The Nag Factor and Bad Design Decisions
Yesterday, the guy from HP came back and delivered a monitor that seems to be in working order. Finally, after ordering the monitor in January I get replacement number three in March that doesn’t have any problems. But everything wasn’t in working order for long. This morning on the bike, my iPod ran out of batteries and shut down after about five minutes. I have a feeling its Nickel-Cadmium battery is about finished. It was a rough hour and it got me thinking.
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.
Enabling ACKs in TinyOS 2.x
Posted by Matt in development on February 25, 2009
I’ve seen a lot of questions about how to enable ACKs in TinyOS and not too many responses. Unlike a lot of TinyOS problems I’ve had, this one isn’t too bad. Some sample code for enabling ACKs is available in $TOSROOT/apps/tests/cc2420/TestAcks. In your configuration .nc file, just wire the PacketAcknowledgements interface:
implementation {
...
MainC.PacketAcknowledgements -> ActiveMessageC;
}
Then, in your implementation file:
module TestAcksP {
uses {
interface PacketAcknowledgements;
...
Then, just before you call AMSend.send() for a message_t testMsg:
call PacketAcknowledgements.requestAck(&testMsg);
When a packet arrives with an ACK request, the ACK will be sent automatically. In the sender’s AMSend.sendDone(), you will want to make sure the packet was ACKed to determine if a retransmission is required:
if(!call PacketAcknowledgements.wasAcked(&testMsg))
retransmit();
And that’s pretty much it.
Upgrading to TinyOS 2.1
Posted by Matt in development on February 25, 2009
I recently upgraded my TinyOS version from 2.0.2 to 2.1 and discovered that it makes use of Java 6. I was testing my installation and kept getting the following when compling TestSerial:
java.lang.UnsupportedClassVersionError: Bad version number in .class file
Changing my java complier and runtime to Java 6 fixed this problem.
TinyOS and NesC syntax highlighting
Posted by Matt in development, info on February 20, 2009
Since I’ve been doing some more work with TinyOS, here is a gedit .lang file that provides nesC syntax highlighting. I got the file from the author of this post on the TinyOS mailing list and it’s been pretty useful. To install it in Ubuntu, place the file in /usr/share/gtksourceview-2.0/language-specs/. Unfortunately, you’ve got to be root to do this and I don’t know of another way to add .lang files if you aren’t. This is a problem for the departmental machines where I don’t have root access, so I can’t use custom gedit syntax highlighting.
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.
Code Size: It’s too big for my head
Posted by Matt in development on February 9, 2009
In all my previous programming projects that I’ve done on my own, I’ve always remembered exactly how everything worked: what every function and variable did and how every data structure and class interacted with each other. In a way, I was able to store and compile the entire source code in my mind and know exactly how it would work. With my current project, I can no longer do that. The code is just too big and I can only remember pieces of it.
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.
Upgrade Headaches…
Posted by Matt in development, general, info on January 29, 2009
Yesterday I installed Intrepid Ibex 8.10 on my aging (now ex-gaming) desktop machine in an attempt to breathe new life into it. I wound up biting the bullet and ordering a new monitor and Xbox 360 for games, so now I’ve got two monitors. Neither the Lenovo nor the Mac laptop I’ve got support two external monitors, so I thought I would give the desktop a try. Though the installation went fairly well, two really annoying things weren’t working correctly, and a third I’m still dealing with.
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.
Recent Comments