Last (Minute) Tests Before Departure

This blog post is two days late because things like shopping and catching up on sleep take a stupidly long time. (As you can see, I gave up on one of these tonight.)

The last long-range tests went well.

The Tang, where resides the amazingly wonderful Tetazoan cruft Chris Calabrese who let us use his apartment many times when it wasn't actually convenient for him, is just under 1.5 kilometers away from the New Media Lab. Cbreezy's 12th floor apartment is actually just a bit below the treeline in front of the E15 roof deck where we had our receiving antenna set up; we didn't quite have line of sight there. But the signal strength was -76 dBm (to out of four power bars- not bad). The Internet speed test on the receiving end didn't work because it was too slow, but google search was decently fast and the HTML version of gmail loaded fine. At the Tang, the speed was around 7-8 Mbps. I think at this point that one of the toughest things about implementing in Tanzania will be that the Internet speed at the source will already be quite slow- less than 4 Mbps for sure. Not sure whether we'll be able to do anything about that.

The second test was almost as long a distance: 1.12 km from the 14th floor of MacGregor to the Media Lab roof deck. This time, we had perfectly clear line of sight, and a high elevation off the ground. The signal strength was -47 dBm (without the 100 ft Ethernet cable in the system), and the speed on the Media Lab end was around 8-10 Mbps (the wireless speed in the same room as the Netgear router). The speed at MacGregor was around 60 Mbps, so there was a loss of about a factor of six. Assuming the loss in speed is directly proportional to the loss in received power (which might not be true), I think that's about 8 dB of loss (10*log(6)). Dunno what that tells me, though.

In the second test, we used our 100 ft Ethernet cable and discovered that the the signal strength seemed to fluctuate between -47 and -61 dBm; we aren't sure why that would be happening, but the speed test didn't reveal any speed difference with the cable so it did not seem to matter.
J (at the receiving end) also moved the computer around to different places to test the range of the Netgear router. There was no difference in speed 25 feet away from the router with only space or a glass wall in between. With a wall between, there was almost a tenfold decrease in speed.

One really troubling/puzzling thing happened: even with the Bullets configured correctly using static IP addresses, when J plugged the Bullet directly into her computer, there was a DNS lookup error. I'm not sure why that would happen, especially because it never happened before when we were testing the same setup at a shorter distance (across East Campus courtyard). This is another question for Ubiquiti tech support.

The promised update having to do with the GPS coordinates of the staff houses and school:

We got them. And then we used Google Earth's Path tool to find the elevation profile along the line of sight paths between the school and the various staff houses and offices that could be our Internet source. The results were amazing.

Elevation profile from Staff House 1 to Orkeeswa along the line of sight path- our best elevation profile

Kudos again to Google Earth, and satellite imaging.
We are hoping that the little hill on the Orkeeswa side of the path (on the right side of the elevation profile, since the path started in Monduli) is right underneath the school rather than behind it. Apparently this isn't just wishful thinking; the coordinates we were given for the staff house was exact, but the coordinates given for the school were actually the coordinates of a girls' school close to Orkeeswa, a little bit further from Monduli. Our IEFT contact tells us that Orkeeswa is likely on that little hill, which would be really awesome, to say the least.

The profiles between the other possible Internet sources and the school were also decent, but not as good.

Elevation profile between the Monduli office and Orkeeswa- not as good

The last thing left to test is whether or not the relay connection will work. The two Bullets at the midpoint (if we use one, which may happily not be the case) are connected via an Ethernet cable between the two LAN ports in both of their POE injectors. We'll do a short-range test on Monday.

I promised the schematic sketches I did. Here is a very drafty and messy second draft that should really be copied over at least once more:

Miscellany:

Things bought/obtained yesterday:
3 pairs of thin long pants
1 floppy-brimmed hat
1 mosquito net for sleeping in
1 huge, garishly pink hard suitcase

Things to buy today:
Lots of bug spray
Granola bars
Travel-size stove/water boiler?
Reading Flashlight (because I dumbly sent all of mine over already)
Blooming teas (gift for host family)

Things to buy at MIT:
Another MIT t-shirt (lost mine)
Screw-cap water bottle

Things to do today:
Go to Apple store, get computer fixed(?)
Email Ubiquiti

Things to do in the future:
Send a postcard to Bello Opticians (348 Shrewsbury Street, Worcester, MA 01604)
Email that random research scientist who asked us about our project in the elevator
Write a post about science lab testing at Hunter

Our Bullet2 Access Point WDS configuration- guest blog by J

Bullet2 Configuration

Connect Bullet2 via Ethernet to computer. Turn Airport off, go to browser, and enter IP address of Bullet2.

Main appears to be a summary of the current configuration and also shows some data, such as signal strength.

Link Setup contains Wireless settings.

Wireless Mode is set to Station WDS (Wireless Distribution System) for the receiving Bullet2 and Access Point WDS for the broadcasting Bullet2.

ESSID is the name of the network, which in our case is OrkeeswaNet. If we end up using a midpoint, we will name the two pairs of Bullet2 modems with different ESSIDs so as to make troubleshooting easier.

Lock to AP MAC is the MAC of the partner Bullet2, so if I were configuring the receiving Bullet2 I would set this field to the MAC of the broadcasting Bullet2.

Output Power can be controlled here, but in our case we want the maximum output, which is 20 dBm.

Security gives a number of options in a drop-down menu, but we choose WPA2-AES because it gives the best protection / bandwidth ratio, basically the best value if we don't need it super well protected.

WPA Authentication is PSK in our case, which stands for Preshared Key.

WPA Preshared Key is basically a password for the network, in our case orkeeswa.

When all of the settings are as they should be, click Change at the bottom of the page.

Network contains settings for the "identities" of the pieces of equipment in the network.

Network Mode is Bridge in our case, since we are basically creating a "bridge" between two Bullet2 modems.

Bridge IP Address can be set to DHCP or Static depending on what we want to do.

IP Address is the "name" you assign the Bullet2 you are configuring. It is standard to assume your "gateway," in our case the TPLink router, is named 192.168.1.1, so we assign the broadcasting Bullet2 192.168.1.2, the receiving Bullet2 192.168.1.3, and so on if we have a midpoint and two more Bullet2 modems.

Netmask defines the range of IP addresses that are available for the router to assign to the individual computers in the network. In our case, the router is the Netgear and the network of computers is the Orkeeswa Computer Lab. We set Netmask to 255.255.255.0, which means that there are 256 IP addresses available for the Netgear to assign to the computers at Orkeeswa. Definitely more than we will need.

Gateway IP is the IP address of the initial router. As mentioned above, it is 192.168.1.1.

Primary DNS IP and Secondary DNS IP are the IP addresses of the Domain Name Servers that handle the Internet requests on the broadcasting end of the setup. In our case, they are not required so we simply filled them in with 1.1.1.1 and 1.1.1.2.

Auto IP Aliasing should be checked.

When all of the settings are as they should be, click Change at the bottom of the page.

OH MY GOD

I am trembling from exhaustion in the Terrascope room. Today was a hard day.
Yesterday was not nearly as bad. I'm going to blog about it first before I forget:

Met with Dr. Chan yesterday. He gave me lots of good advice about the setup of the system, such as never to keep the routers and non-weatherproof electronic equipment outside, even in a weatherproof box. Also, to keep moisture out of the attachment between the antenna mount pole (probably steel) and the grounding wire (copper), we should seal it in with epoxy resin to keep it from becoming a galvanic cell and corroding. (We bought this at Home Depot today.) Instead of mounting the antenna on top of the roof, we should mount it on a pole clamped firmly to the side of the building. Also, with 0.7 km of testing distance and 7 km of goal distance (a factor of 10), we should look for 20 dB of margin (difference between the signal strength/gain of our link and the minimum sensitivity) when we do the 0.7 km test. Since each 100 ft Ethernet cable attenuates the signal about 24 dB, if it works at all with a 100 ft Ethernet cable, that should qualify.

Our only real test that day was between Tang and the MIT West Parking Garage (~0.7 km). Ben was there to help carry things, which made everything much easier. It worked fine with the window open, but just barely with it closed (Dr. Chan suggested there might be a metal coating on the glass). Ben told us about a website called speedtest.net, which tests the upload and download speed of your Internet connection, and we found that the broadcasted Ethernet connection speed at Tang was 6 Mbps/8 Mbps (upload/download or vice versa, don't remember) and the received connection speed at the garage was around 2-4 Mbps upload and download. We also tested the signal strength of the connection, which can be found as a number (in dB) on the "Main" page of the Bullet configuration utility AirOS, which you access by plugging the cable coming out of the LAN port of the POE injector into your computer and typing the IP address of the Bullet into the URL bar of a web browser. The signal strength with the 100 ft outdoor rated Ethernet cable was -69 dB (negative gain because we had net losses over the link, not gains). The strength with only a 25 ft non-outdoor Ethernet cable was -71 dB- no idea what to make of that. Maybe the outdoor Ethernet cable isn't so lossy because it's shielded. The sensitivity of our receivers is around -96 dB, so we have a good 17-dB margin, which almost meets Dr. Chan's 20-dB margin requirement even with the 100 ft Ethernet cable. We're good.

Then we scouted for places to test at longer distances. We checked out Vassar street (~1.5 km) from Stata to where Tang is, and MacGregor's lounge windows (which conveniently faced in the right direction). We also found E15's roof deck on the 6th floor, which looked out in the direction of both MacGregor and Tang. Planning is power.

Today:

I lost my mind in the heat.
An Ethernet cable was shredded. I'm going to have to learn to solder on new Ethernet cable heads as well as N-male and female heads onto LMR400 coax cable.
There was a success, and a failure (both unexplainable).

The first place we tested was a short-range test down the Stata block on Vassar street, maybe a hundred meters. I didn't realize until I got there with all the equipment that there were no Ethernet jacks on the ground floor near where I had to be. On the fly, I had to set up my MacBook to share its wireless Internet connection with the Bullet while halfway in and out the door with pedestrians flooding by all the time. It was mostly simple (you go to "Sharing" in System preferences, check the Internet Sharing box, and the settings are "Share Airport Connection" and "over Ethernet" or something like that), but the tricky part was that I had to reconfigure the Bullet to use DHCP rather than a static IP address. All I remember about that stressful moment was that I kept all the settings I'd had before, but set IP address in the Network tab to DHCP. It worked fine; full bars. Then I went back to disassemble everything, and realized that the 100-ft Ethernet cable was slowly being skinned by being squeezed between the bottom of the door and the no-slip doorway, and then the door sliding back and forth on top. The plastic jacket was torn to reveal the metal shielding underneath. :( People also apparently thought it was okay to ride their bikes over my Ethernet cable, even when I waved my hands and shouted not to when they were far enough to slow down. It wasn't okay. I almost cracked in the heat.
Speedtest.net said I had an upload speed of 45 Mbps, and a download speed of 60 Mbps on Stata's MIT wireless network. It said J had an upload/download speed of 1-3 Mbps, which was probably because of the damaged cable.

The second place we tested was between the 14th floor lounge of MacGregor tower and the MIT West Parking Garage. I reset the Bullet (because it wouldn't let me access it using the IP address while on DHCP- maybe I should have tried to find out what IP address my MacBook had assigned to it) and reconfigured it to use a static IP address. We got full bars, both through the glass window (thankfully uncoated with metal) and the mesh screen on the windows that opened. Success.
While I had a download speed of 93 Mbps and an upload speed of 65 Mbps, J had upload/download speeds of about 2-4 Mbps. The signal strength found on the Bullet configuration main page was -66 dBm.

The third test started at around 11 pm. We'd started testing at around 5. It simply took forever to move stuff around to the different locations. I'd found a shopping cart in MacGregor and had tried to use it to carry everything; it didn't work because the shaking of the cart on the bumpy ground shook the screws out of the antenna and the feed fell out. :( I was afraid the bumping would be bad enough to damage the electronics in the router and Bullet, so I took those out too after reassembling the antenna as best I could in the middle of Memorial Drive (with the copious extra screws, nuts, and washers provided by ZDA Comm- go them!). By the time I got to my location in Stata, my hands were shaking and I was confused with tiredness. I thought the antenna was assembled incorrectly, so I reassembled it (incorrectly), then realized my mistake and re-did it correctly. Then I re-mounted the huge 3-ft wide 24 dBi monstrosity- a difficult job for a single tired person. It took a long time, and J sadly had to wait out at her location in the heat for me to finish (I'd had to help carry her stuff over at the Tang end of Vassar before coming to set mine up). Then I reset the Bullet, and tried configuring it again to use DHCP. I was apparently unsuccessful, because half an hour went by and we had four bars of signal, but no Internet service on J's end. There was apparently an error message pertaining to configuration. I reset and reconfigured the Bullet again, but the same error message appeared. :( I'm not sure what went wrong, but I will try again tomorrow starting with the configuration for static IP on the broadcasting Bullet (which I definitely got right). We will also probably not need this function in TZ of making the Bullet get Internet through a MacBook, but it'd be a backup plan. I'll also need to call Ubiquiti tech support about this not-being-able-to-access-configuration-when-Bullet-using-DHCP problem.

We had Greek pizza in the Terrascope room at around 1 AM. Maybe I like olives now.
I'll post my detailed conceptual drawings of the setup tomorrow (which I did while getting my glasses fixed), as well as some good things we found out about the actual locations in TZ. Like the GPS coordinates, and thanks to Google Earth (<3<3!), the elevation profile of the land across the line of sight! Which is looking fantastic, btw.

-E

Configuration and Confusion

Exciting things happened today.

To start, I ate some really good bread at J's house. The label said "Sunday garlic and cheddar artisan bread," but the most notable thing about it was the large quantity of poppy seeds scattered throughout; it tasted like a poppy seed bagel, but was soft and fluffy like whole wheat bread! Miraculous.

There are more changes to the system. I'm still hoping to try the thing where we cut out the first Bullet, but for now we're going to keep it just to make things simple. According to the Internet, not all WDS-enabled devices from different manufacturers can work together. So now we have four Bullets and four antennas.

Configuration setup for two-hop link. I will write in the antenna specs, cable lengths, and types as soon as those are finalized.

The testing will go differently than I thought. Now we can only test a link of about 0.7 km tomorrow, because we can't actually configure just three Ubiquiti Bullet modems to repeat a signal over many miles from the first to the third link. So says a tech support person from Ubiquiti Networks.

I don't entirely understand the reason yet, but this is what I gathered from what the tech support person told me: In the case that I only had the omnidirectional antenna at the midpoint, Bullets #1 and 3 would have to be configured as WDS Stations (receivers) and Bullet #2 would have to be the WDS Access Point. (See picture above for what these terms mean.) Since the access point would only be able to send out signals to within a certain radius (of no more than a few thousand feet), they would not be able to "hear" the access point even if the access point could "hear" them.


What confuses me about this reasoning is that if the directional antennas at the receivers are powerful enough to send out signals that will reach the midpoint Bullet, why wouldn't they be able to pick up signals equally far away? I had read that increasing the gain of the antenna at one end of a link strengthened the connection as a whole, not just one end. So even if the antenna on one side of the connection had a lower gain because it was omnidirectional, the very high gain of the directional antenna on the other side could make up for it. But does that only apply when both antennas are directional? I'll have to look that up. I might still be right.

But for now, I've bought another Bullet and POE injector to set up the network as the tech support person recommended, because I can! We happened to have two extra 19 dBi antennas that we had been planning to replace with the 24 dBi ones; now we can use all four, which is a much more powerful combination than the two 24 dBi's with the 12 dBi omni in the middle. This way we will have a much narrower Fresnell zone (the football-shaped area in which the signal travels between antennas), and our antennas' limited height above the ground (limited because we're putting them on roofs, not towers) may not matter so much.

Then again, adding an extra hop will cut the bandwidth in half. So unless we get to Tanzania and see that there are definitely large trees or buildings blocking our line of sight, the main plan is to create a single-hop point to point link using only our most powerful antennas. The two extra Bullets are backup.

More things I learned from Ubiquiti tech support (way to go, them!):

It's easiest to troubleshoot a multi-hop link when each machine on the link has a distinct static IP address. So the two main broadcasting and receiving Bullets are 192.168.1.2 and 192.168.1.3, respectively. The two backups will be 192.168.1.4 and 192.168.1.5, and whatever 3G router is acting as their Internet gateway will be 192.168.1.1 (as is default and proper for a consumer router). Since the AirOS interface for Bullet 2 wouldn't let me change their IP addresses without specifying DNS server IPs, I was instructed to put bogus IPs (1.1.1.1 and 1.1.1.2) as the primary and secondary DNS servers for all of them; apparently it doesn't matter, because the 3G router would be handling the DNS stuff. Very interesting. I wonder how the different devices tell each other these things.

What I have left to do today is figure out all the cable lengths and draw a picture for my UROP adviser so he can hopefully approve some cable purchases. Then maybe a run? And sleep.

Random note: Dyed my hair bright red in honor of the Maasai colors (red and black). I hope they approve! (Second best option: I hope they don't notice!)

-E

Remind Me Never To...

1. Order anything from a company whose website is broken- ever again!! I tried to order 50 ft of AWG 4 ground wire from Hutton Communications a few hours ago. The website gave me two error messages and then the order finally went through, but then I got a receipt claiming I had been charged triple the price on the website, and that the item was on backorder until July. I am very unhappy about this. I called them and left a message; hopefully they'll get back to me.
2. Wait until 2 weeks before departure to do final calculations and nail down what the system is going to look like-complete with cables and lengths, sketches, antenna mount designs, testing methods. A week is too short to get a whole bunch of equipment without rush order, especially from companies with broken websites (!!!). And then we'll have to be testing in the final week. Too short.
3. Go 5 days without making a new sketch of what the system will look like. A month before deploy, this should shorten to 3 days.
4. Eat only mozzarella sticks for dinner. Or thick-crusted pesto pizza- there's really too much bread there.
5. Have trouble sleeping

AARRGGHHHGHHHHHHGGRRRRLL
*Angst Angst*
Okay, I'm done.

-E

Wednesday Plans: 3-Point Testing

Mostly for the benefit of J's friends Ben and Julian who are helping with the testing on Wednesday:

The goal: to set up a three-point Internet link in which we broadcast Internet signal from the first point and give Internet access to the third point (which normally wouldn't have it). The first point will have a large directional dish antenna broadcasting the signal directly to a midpoint antenna that receives and broadcasts in all directions- the midpoint is the one you'll be manning. The third point will also have a directional dish antenna receiving signal from the midpoint antenna. (I'm using the terms "broadcasting" and "receiving" to refer to the Internet access; in reality, all the antennas are both sending and receiving signals in the process of communicating.)

At the midpoint, you won't have to do any aiming; while the two endpoints move around and try to find the best angle to point our antennas at, you should stay in the same place and keep the antenna oriented vertically. (The only exception is if the connection isn't working and you see some object blocking the lines of sight between our locations and yours; then we might ask you to move.)

The setup: You'll have in your possession a portable battery pack, into which you should plug the Power over Ethernet (POE) converter (the little black box-looking thing that has one or more Ethernet cables coming out of it). The POE converter's "POE" jack should be connected to the Bullet modem (cylindrical tan device) via an Ethernet cable, and the Bullet should be connected to the antenna. (We'll make sure everything is connected okay before we begin.)

This will be the order of the testing locations:

Test 1: Tang Hall (broadcasting) to MIT West Parking Garage (midpt) to MacGregor (receiving)- 1.15 km total
Test 1a. If Test 1 works, the next test will be Tang to Parking to Tang side field- 1.25 km total
If this works, we're done!

Test 2. If Test 1 does not work, we will try Tang to Simmons to MacGregor- 0.61 km total
Test 2a. If Test 2 works, we will troubleshoot Test 1 and try again.

Test 3. If the previous two fail, we will try Tang to Tang side field to MacGregor- 0.36 km total
Test 3a. If Test 3 works, we will troubleshoot Test 2 and try again.
If this doesn't work, we will think very hard and try to figure out why.

Example test route: Test 1, from Tang to MIT West Parking Garage to MacGregor dorm

Changes

There are a lot of flaws in the system right now, but I am working on fixing them as best I can.

The foremost in my mind is that there are currently 100-ft Ethernet cables at each point in the network providing power and data to the Bullet modems, which at the two endpoints cause signal attenuation at 0.24 dB per foot- quite a high loss rate. If there is a midpoint in our network to relay the communication between the two end nodes, I'm not sure what a 100-ft Ethernet cable at that point would do to the signal. Since there's no new communication originating at the midpoint node, it's possible that the signal wouldn't be attenuated there at all; the 100-ft Ethernet cable would essentially act like an extension cord for powering the Bullet.

That being said, the better thing to do here is to use some low-loss cable such as LMR400 or higher, just long enough to minimize the guaranteed attenuation but at the same time make the cable unlikely to be too short (which would actually not be disastrous, given that a long enough extension cord could probably make up the difference). So the question is how much new cable do I need to get?

Assuming I'm circumventing the Bullet on the broadcasting side (which I probably can do because I think the TP-Link 3G router is just as strong a transmitter as the Bullet, but I'll have to check that), I only really need a small amount of cable to reach the router, which can be kept in a weatherproof box on the roof close to the antenna with an extension cord running up to power it. On the receiving end, I will actually need a large enough length of cable so that the Ethernet cable from the Bullet to the Netgear router can be really short. (This means the whole Ethernet cable will be indoors, and since I already have a nice 3-footer, I won't have to buy a new one.) That will probably mean between 30 and 50 feet of coax cable (with one N-male end and one N-female end, of course!).

The silly thing is that this wouldn't be a problem if I hadn't already wasted money on the 100-ft Ethernet cables. This would be a non-issue if I wasn't on such a limited budget provided not by some huge corporation, but by MIT community member donors through the Public Service Center. But to trace the whole situation back to my own failures as an engineer, I had no idea that you could lose so much data over Ethernet cables. As I now realize, Ethernet isn't a type of cable, it's a protocol that runs over particular types of cable- namely Cat5/Cat5e/Cat6/Cat6e, which consists of four twisted pairs of copper wire set up in a particular way (twisted to minimize inter-wire interference via magnetic induction). Moreover, this cable isn't formulated to be particularly lossless, unlike the better insulated LMR-higher number coax cables and above. Stupid, stupid.

The other changes in the system I've probably already mentioned in the rant above, but here they are more clearly stated:

One of the engineering goals in this project is to minimize components and costs so that the system can be affordably implemented elsewhere. I want to try the system without the first broadcasting Bullet, so the TP-Link router is broadcasting the signal directly out of its RP-SMA female antenna jack and out the directional antenna, instead of supporting the link as a user on one of its Ethernet ports. I think this should be an improvement because I think (and I'm not sure why; I think it might be written on the device somewhere, but I could be wrong about this) the TP-Link's transmit power is greater than 20 mW, which is what the Bullet's transmit power is. I'll definitely have to have the answer to that by tomorrow morning, since it determines how I'm going to configure the Bullets in my network (with 3 or 2).

That brings me to the next change- to add a midpoint consisting of a 12 dBi omnidirectional antenna and Bullet to act as a relay. In case there's a whole row of trees situated along the line of sight- we simply can't have that. This relay will require another mounting pole, grounding wire, grounding rod, and Ethernet cable (or coax cable + extension power cord, if attenuation matters) in addition to the Bullet, POE injector, and powerful omni antenna (which are really expensive, long, and unwieldy! Mine is almost 5 feet long). Expensive, but unavoidable without adequate knowledge of the terrain. This project would be better done by thorough scouting in-country first, then buying all the parts and going back. But plane tickets are expensive.

Finally, the 19 dBi antennas are being replaced by more powerful 24 dBi antennas, because the old ones worked fine in open air but even a few trees in the way would attenuate the signal to nothing. The new antennas (from Zda Communications, a wireless hardware manufacturer based in SC) are each less than $30 more than the old ones and have much better directionality (narrower beamwidth); we'll still need to have line-of sight, but we'll be able to avoid trees more easily, and hopefully the stronger signal will be able to penetrate that one tree we simply can't avoid. I should have invested the extra money to get them in the first place, but didn't in an effort to cut costs early on. I guess this is why researchers make the heavy investments first to get a product working, and then try to cut costs afterward.

More on failures as an engineer: Next time, I'll have to make sure to buy the antenna with the CORRECT GENDER connector so we won't have to waste another 3 dB of attenuation on the connector converter.

That is all.

-E

Status Update: Testing Testing

Whew, it's been a long day and all I've done is bike around MIT and respond to emails.

This post is an overview of the challenges we are facing at this point in the project.

1. We have not yet been able to establish a stable link over a distance of more than 0.2 km. (By stable link, I mean the Bullet repeater modems on both sides register some received signal power that does not spontaneously flicker on and off.) We were only able to achieve transient connections over the longest distances we have tested at (0.4 km at Wellesley College, and 0.8 km between the top floor of ADPhi fraternity house and a 3rd floor apartment in Cambridge). We think that this is due to obstructions such as tall trees and buildings.

We will proceed by finding better testing sites with actual line of sight connections between the two ends of the link. Hopefully this will allow us to decouple the signal-attenuating effects of long distance and obstructions, which we should not have much of in Tanzania (although we can't know for sure). After a scouting trip around MIT by bike and a stunningly accurate fly-through of campus on Google Earth, a few locations look particularly promising, although none of them are more than 0.6 km:

McCormick to the Tang (grad dorm) side of the field- 600 m
Tang to McCormick- 600 m
Tang to MIT West parking garage- 600 m

View across the MIT rugby field, taken from the Tang side. The tall building to the right is McGregor dorm. The tan building a bit further away (directly to the right of the white bulge) is McCormick dorm.

We are also planning to upgrade from the 19 dBi directional antennas we have been using to 24 dBi antennas, which are only around $15 more expensive, which we should have gotten in the first place. (To get from 24 dBi to the 27-30 dBi range is apparently another story! The two I found at 27 and 30 dBi were huge dishes 6 and 8 feet in diameter, respectively.) And if the link still isn't strong enough, we need add the third repeater modem at a midpoint, and reconfigure the Bullet modems to obey the new network structure (put in new IP addresses and make them recognize different receiving and broadcasting machines).

2. We do not know if it is possible to use 3G routers to access the Internet in Monduli. In the current system, a 3G modem provides Internet access to a 3G router, which in turn provides it to the Bullet modem through one of its Ethernet ports. It is possible that none of the ISPs that provide service to Monduli use 3G modems that are compatible with any 3G routers, whether it is the TP-Link MR3220 that we are using for testing, or any 3G routers available in Tanzania. I also think it is possible that the networks in Tanzania are not configured to allow 3G routers to access them, although I am not sure how they would do this.


The solution might be to use a computer as a router; all models of 3G modem must be compatible with computers in order to function. The mobile broadband connection can then be configured on the computer to be shareable with other computers on the network, where the "other computer" can be a Bullet modem. I have so far been able to share a mobile broadband connection (the prepaid Verizon service I am currently using to test) using a Windows 7 laptop and a MacBook, but encountered difficulties on my Windows XP netbook; even with the same configuration as in the Windows 7, it will not share Internet access. I'm not sure what's going on there. The good news is that there are several old MacBooks at the Orkeeswa school, so if they are all in working order, I should be able to use one of them as a router.

-E

Introduction

Myself:

I'm a sophomore at MIT, in Computational Biology. I'm currently curled up in a ball of warm on J's couch in Shrewsbury, covered by a mound of earth-colored blankets and cushiony things. On the 28th of June, I'll be departing for Monduli district, Arusha region, Tanzania.

This Project:

J is my project partner. Together, we are trying to make it possible for the students at the Orkeeswa Secondary School to use the Internet without having to drive two hours from their rural location to the nearest Internet cafe. The method is to set up a point-to-point connection from the school to a house for volunteers in the town of Monduli, where there is reliable cell phone service. From there, we will access the Internet using a 3G mobile device and use a router to convert the signal to the unlicensed 2.4 GHz 802.11b/g band, and we will send that signal 4-5 miles to the school through the open air using two 19 dBi directional antennas (one broadcasting and one receiving).

We will also be helping to set up the new science lab at the school by preparing demos and experiments using locally available materials; you may also hear some tidbits of that as we go along.

This log is mostly for me, to help keep track of what I know and what I need to figure out. Someday it may be mostly to provide useful knowledge to other people doing projects of a similar nature.

Huzzah!