One idea that’s been bouncing around in my head for the last few years has been a laptop with an E-Ink display. I would have thought this would be a niche that had been carved out already, but it doesn’t seem that any companies are interested in exploring it.
I use my laptop in some non-traditional environments, such as outdoors in direct sunlight. Almost all laptops are abysmal in a scenario like this. E-Ink screens are a natural response to this requirement. Unlike traditional TFT-LCD screens, E-Ink panels are meant to be viewed with an abundance of natural light. As a human, I too enjoy natural light.
As would be familiar to anybody who knows me, I’m always interested in new tech, especially when it’s running free software and portable enough to be in my every-day carry arsenal.
For the past month or so I’ve been looking at a few devices as a secondary to my laptop to carry with me. In a few weeks I’ll be joining those already there at third installment of Hackerbeach, on the Caribbean island of Dominica.
I wanted an embedded Linux system that could do everything. The scope of this device just kept getting bigger the more I thought about it.
This post deals with the technical challenges we’ve encountered while trying to establish reliable communications while staying in Rural Kenya. Some background information is necessary to understand the efforts we’ve gone through to remain connected.
This year the prestigious Hacker Beach event is taking place on the island of Lamu off the eastern coast of Kenya. The island is serviced by a single UMTS tower located above the hospital in the main town of Lamu City. However, our accommodation is on the other side of the island.
Our accommodation had a previously installed directional antenna on the roof to provide internet access. Unfortunately the access was very slow, with only 14% signal strength. This was complicated by strong winds blowing against antenna, causing it to be pointed in a wrong direction. This further reduced the cellular reception, sometimes making it disconnect completely.
An additional problem was that WiFi was served by a single Cradlepoint MBR1000 router in a corner of the fort, making it inaccessible through the impenetrably thick fort walls. This meant we were limited to camping in the upstairs dining hall, which worked well enough due to all the seating, but there was some desire to branch out to work from other areas of the fort, such as the knights-of-the-round-table-esque meeting room.
For a group of 18 hackers, this level of connectivity was unacceptable. Many of us were making excursions into town to work at cafes with better reception. This was a problem because it threatened to undermine the spontaneous collaborative nature of Hacker Beach. The way we saw it there were two problems to fix:
Reception of the antenna was abysmal. Was this an inherent problem with the location?
WiFi reception was limited to only one corner of the house. Ideally the house should have WiFi everywhere.
We attempted to fix this by purchasing local SIM cards and installing them in portable WiFi Hotspot devices. Oddly enough we were able to receive some 3G reception if the devices were placed in some rather random areas of the fort. Unfortunately the connectivity of these devices wasn’t reliable enough for full-time hacking. So we began efforts in earnest to fix the connectivity problem.
We determined that the most appropriate solution to the WiFi problem was to employ PowerLine Ethernet adapters throughout the Fort to distribute connectivity. Simply repeating wireless signal was not a good option because of the lack of strategic locations to place wireless repeaters. The thick walls meant that the signal would be stopped between floors as well. We took a gamble and assumed that most outlets would be on the same power phase (if circuits are on different phases the PowerLine throughput will be severely limited, or likely not work at all). Since we had some new hackers approaching in a few days shipping was out of the question. Thankfully we were able t source some units in Athens, which (after some begging) our gracious friends were kind enough to pick up and bring for us.
The pairing part was easy, with WiFi SSID/password being copied using WPS. After pairing the devices could be moved anywhere in the fort to increase coverage. We installed two devices which are able to blanket the whole fort with connectivity. Problem solved.
Next was a trickier bit that required more calibration and special equipment. While inspecting the old antenna we found that the connectors had been tortured by the elements for several years. This meant that the antenna pigtail connectors were rusted, which was likely causing reception issues. Another problem was that the pigtail was being run through a window, which was then closing on it. We feared this was crushing the cable, which could have easily caused our antenna to become useless.
There were several more hackers arriving from Nairobi in a few days, so we asked them to bring some antenna gear to hopefully help improve our connectivity. In total a questionably-EDGE amplifier, directional antenna, and some cabling was delivered when the hackers arrived early yesterday morning. It didn’t take long for us to tear it all open and start installing it.
Equipped with a laptop, an antenna, and a downstairs accomplice we disconnected the old antenna and threw a new line down to connect to the 3G modem. Next I had opened the router’s modem status page to measure signal strength while another hacker determined the direction the antenna should face to get the best reception. Our best direction was pressed against the old antenna; the people who installed the last one must have known what they were doing.
Unfortunately we were only armed with my multitool which meant that proper mounting was going to be impossible. We tried wrenching the existing nuts that held the antenna in place, but they proved to be well stuck with a decade of rust and generally brutal African elements. Not even cooking oil (our improvised WD-40) would help loosen the offending nuts. Ultimately we ended up doing a bodge job to keep the antenna in place. One of the hackers had brought string with him, which we used to tie the new antenna’s base plate to the old antenna. This worked surprisingly well, although is a horrifyingly temporarily solution. The string will not stand up to more than a few days outside here. Next we plan to source some tools locally and perform a permanent installation of the antenna.
With the old antenna the signal strength would consistently be about 14%, which resulted in throughput of about 200 kbit. After out new antenna was installed and calibrated we were able to see signal strength of up to 80%, which gave us upwards of 1800 kbit of throughput with consistent pings of about 250 ms. Hooray!
After applying liberal traffic shaping on the router we are now able to comfortably surf the internet, download packages, and use IRC.
That’s right boys and girls. I’ve started compiling RouterStation Pro OpenWRT nightly builds for all punks who like to live on the edge. From my testing these images are rather stable, and aren’t prone to consistent or serious issues. Since this changes nightly your mileage may vary.
I recently had more time to investigate my earlier problems with the GuruPlug. The problem was discovered by somepeople on the plugcomputer.org forum. The problem stock U-Boot is that is incorrectly reports the arcNumber. The solution then, is to upgrade U-boot!
After a failed flashing attempt(don’t attempt to tftp flash u-boot.kwb from within U-Boot!) I needed to use JTAG combined with the included JTAG adapter. To do this, make sure that the UART cable is unplugged, and the JTAG cable is plugged in(unplug/replug the USB adapter just to be safe). First grab the guruplug-installer package, then grab a known-good copy of U-Boot.
I’ve recently taken ownership of a GuruPlug, and naturally the first thing I tried to do when I got it was to install Gentoo on it. I first went to build a kernel using the GuruPlug patches on a vanilla 2.6.34 kernel, which ended up disasterous. I applied the patches, however the kernel ended up not booting.
At which point I decided I wanted to try to restore the original kernel, so that I would at least have a working system with which to test. Therein lied the rub. The files posted here are completely broken.
In an effort to upgrade my network from the aging–and failing WRT54G’s, I purchased a RouterStation Pro. A RouterStation Pro is an embedded Linux board with some impressive hardware specs. The part that appealed to me was the 3 Mini-PCI slots that allowed me to use wireless cards that had support in the Linux kernel. There’s a large portion of 802.11N routers that are using Broadcom chipsets which are only supported by a proprietary blob(wl.ko).
The RouterStation Pro comes preloaded with a relatively old installation of OpenWRT Kamikaze. Being a sucker for bleeding-edge software, I definitely wanted to check out code from the main Subversion repository to get it up-to-date as far as development goes. Here’s how I did it.
I’ve been to several LAN parties recently, and have been getting a very accurate understanding of how much a pain it is to lug around a 30lb case, 30 inch monitor, and all the accessories. I’ve looked at gaming laptops; they all seem too expensive, too expensive, and too slow compared to something I could build myself, for cheap.
In an effort to modernise my gaming rig, I purchased a second nVidia 8800GT to compliment my first. Benchmarks and reviews indicate that this setup yields comparable performance to many of today’s more expensive offerings. This is a log of the installation and testing of the cards.
Recently I picked up a Fujitsu P1620 on eBay. I’ve grown to really appreciate all the hardware in it, and consider it grade ‘A’ hardware, except for a few gotchas in Linux. This serves as a document for those who are seeking to gain full hardware functionality of a P1620 in Linux.