|
|||||||||||||||||||||||||||||||||||||||
|
By David Rowe, on August 30th, 2010
  I’ve just blogged on the latest stage of the Dili Village Telco roll out in Timor Leste. Fascinating what can be learnt from a real world deployment. I find the social and business issues just as fascinating as the technical problems us geeks usually focus on.  Test call by HAFOTI Director. HAFOTI is an NGO working on Womens issues in Timor Leste Links 1. More photos of the Dili Village Telco roll out. By David Rowe, on August 7th, 2010
The V1.3 (production) Mesh Potatoes has an etched (PCB) antennas. This post talks about how we tested this antenna and verified the V1.3 design. Testing at Atcom in June In June I was visiting Atcom in Shenzhen, China. The first 1.3′s were calibrated and ready for testing so we headed out to a nearby open area with some MP01 V1.2 and V1.3 prototypes. We taped a V1.2 and a V1.3 back to back on a length of PVC pipe to compare results at roughly the same height. Lead-acid batteries were used for portable power.  MP01 V1.2 and V1.3 back to back We did some A-B comparison tests, e.g. a V1.3 to V1.3 call then a V1.3 to V1.2 call and V1.2 to V1.2 call. As well as making calls we measured the rx signal strength using the node_tune.sh script. We wandered about and tested at various ranges. Edwin and Alen seemed happy that the two antennas (V1.2 omni and V1.3 printed antenna) worked about the same. This is consistent with the tests Jeff and I performed last December. The node_tune.sh script reports rx signal strengths to a laptop. It’s hard to be precise as the levels bounce around by several dB. Also we must remember the signal strength indicator on a AR2317 SoC is not a calibrated instrument, it’s just a rough estimate. Typical result might be -70 +/- 3 dBm over 10 signal strength samples. As near as we could tell, the results were about the same for the V1.2 and V1.3. Given it was an inner city site there were other networks on the same channel so ping times bounced about a bit. Despite that the guys managed to make OK phone calls up to about 350m, with the V1.3 only a few metres above the ground. At that height 350m between omni antennas is actually better than I have achieved in Dili or Adelaide. Not bad considering we were in the middle of a city of 12M people. Time to introduce some of the Atcom guys. From the left we have Nick and HeZhong. Alen (the MP01 hardware engineer) is in the blue shirt, and Edwin is on the far right holding the potato stick.  Atcom Guys It was about 30C and 95% humidity but still nice to be outside. Everyone seemed to enjoy themselves, and it was good training for Atcom in antenna testing. For example when we walked behind a tree the phone call dropped right out, a few steps to one side and the call came back up. I have also used the “potato on a stick” training method with great success in East Timor. Quick and fun education in Wifi propagation. Testing on the Jetty By July I was back in Adelaide. Time for some more potato testing. Joel and I repeated the tests on the Jetty with the V1.3. The site and path (400m Line of Site) was the same as the January tests. The call quality was fine with the MP in any orientation (I rotated it during a call), even kicking it around on the surface of the jetty with my feet. Pretty similar to January’s results with the prototype PCB antennas. The audio would drop out when Joel stepped in front of his MP but seemed to come back up after a few seconds. Perhaps the Wifi bit rate automatically dropped to account for the extra path loss of Joel! Checking the Antenna Impedance Next I hooked up my Standing Wave Ratio (SWR) bridge to the MP V1.3 antenna. The SWR bridge is described in this earlier post.  SWR head, microwave PCB made with a Dremel tool The SWR bridge lets me test if an antenna is resonant. If it is resonant the antenna impedance will look like a 50 ohm load at 2.4GHz. The SWR bridge can also be used to compare the V1.3 PCB antenna with other Wifi antennas. As described in the earlier post the SWR bridge produces a DC voltage that indicates the mis-match in the antenna impedance from the desired 50 ohms. A low voltage from the SWR head is a good result. Here are the results:
The MP V1.3 PCB antenna is very close to the “ideal” 50 ohm resistive load. Although with this rough home-made kit a fairer conclusion is that the V1.3 antenna is in the same ball park as the others. The SWR head & V1.3 antenna was driven from another Mesh potato sending ping floods. A 2.4GHz signal generator would make this testing easier. Using a Wifi transmitter as a signal source means bursty TX signals which makes these measurements tricky. A 2.4GHz sig-gen I could sweep (even manually) would also be great to determine exactly where the antenna is resonant.  Testing the V1.3 Antenna SWR MP01 Antenna Options The V1.3 has a group of three 0-ohm resistors that can be used to change the antenna configuration. The resistors simply act as shorting links, they could be replaced by blobs of solder:  PCB Antenna and Mode Select Resistors  Close up of Mode Select Resistors and J4 The normal configuration is R406 and R404 loaded. This connects the AR2317 SoC to the PCB antenna. To use an external antenna, R406 and R402 is loaded. This connects the AR2317 to J4, where a pigtail can be used to connect J4 to the external antenna. A third possibility is R402 and R404 loaded. This removes the AR2317 from the circuit, and allows the PCB antenna to be connected to J4 for testing. This is the configuration I used for testing with the SWR bridge in the photo above. A 2.1km Test between Jetties On 3 August we made phone calls over a 2.1km path using two V1.3 MP01s with the built in omnidirectional PCB antenna. The phone calls were of excellent quality (no pops or clicks). Thanks very much to my friend Angelo (a local Electronic Engineer) who helped out on the day. These tests take hours to set and perform and it’s great to have a friend to help.  Angelo on Grange Jetty Angelo is an IT Sys Admin by day and loves trouble shooting. During the Wifi test set up we (quite accidentally) stumbled across a previously unknown but serious bug in the Power over telephone Line (PoTL) part of the power supply. Just in time to prevent the bug being repeated 500 times in the first production run! Thanks Angelo for helping us track this bug down. For the Wifi tests we used two local jetties (Grange and Henley) which extend 500m out to sea. This reduces interference from nearby Wifi networks and gives good height above ground (sea) level. Below is Grange Jetty as viewed from Henly Jetty. Sorry about the grainy image below. Grange Jetty is so distant it is hard to image with the camera I have. Angelo is the guy with the brown eyes standing just behind the canopy at the end of the jetty.  Grange Jetty viewed from Henley Jetty, 2.1km away Angelo suggested we could have gone much further. I think I agree, as doubling the distance again is a only a further 6dB power loss. But we have run out of convenient jetties for now. These results, like the earlier results above, show that the V1.3 PCB antenna is working very well. I would like to take this opportunity to thank Jeff Wojtiuk for doing an excellent job in designing this antenna. Thanks Jeff! I would also like to thank Alen Chen from Atcom who has done a fine job on the PCB layout and hardware engineering for the MP01. Some test data and results, gathered from the Henley end of the link:
I used the node_tune.sh script to measure received signal strength while rotating the Henley end MP01. The signal strength varied between -90 and -86dBm over 360 degrees, with a peak (-86) being reached with the front of the MP01 at 90 degrees to Grange Jetty, i.e. the PCB antenna was edge on. This is an unexpected result. We tried rotating the MP01 at the Grange end. In this case the maximum signal strength was reached with the MP01 facing Henley jetty. This is the expected result. The difference between the two sites makes me wonder of other factors were involved. For example multipath due to reflections from the sea or nearby metal objects. Rotating could also have induced a Wifi bit rate rate shift (e.g. from 5.5 to 1 Mbit/s). The AR2317 transmit power varies betwen 15 and 20dBm between 54 and 1 Mbit/s. A rate shift over the link would cause lower lower tx and hence rx power but a higher bit rate. I performed the rotation tests during a regular phone call. Perhaps using broadcast packets would have been a better idea, IIRC they are transmitted at a fixed bit rate and hence fixed power level. It is important to remember that the AR2317 RSSI indicator is not a calibrated measuring instrument. It is probably not very logarithmic, and no doubt drifts all over the place with temperature and varies from unit to unit. Burst Wifi and interfering signals make power measurements difficult. So we can treat the received signal levels as indicative only. For example I assume an error of +/- 3dB on any RSSI measurements in this system. A much better way to measure RX signal power is to use a spectrum analyser as the receiver. Using a Wifi calculator I checked the free space path loss and Fresnel zone clearance. The expected power at the receiver is: Pr = Tx power + Tx antenna gain – path loss + Rx antenna gain Plugging in the numbers we get: Pr = 17 + 2 – 106 + 2 = -85dBm The driver reported the received power as -86dBm, which is a reasonable match if you trust the received power measurement (which I don’t). Still, it’s fair to say we are in the ball park, and that both the antenna and MP01 radio are performing well. Crystal clear VOIP over a 2100m Wifi link with just Omni antennas and 50-100mW is an exceptional result. I plugged in 17dBm for the tx power above as I was unsure of the bit rate, unfortunately I don’t know how to read the current bit rate of the Wifi driver in ad-hoc mode. The actual tx power could be between 15 and 20dBm, depending on the bit rate. The 1st Fresnel zone was 8m which we should clear OK with our masts and the jetty height above sea level. However I am not sure what effect the sea has on Wifi. Being slightly conductive it’s probably more reflective than a path over land. These results show us how important interference and Line of sight (LOS) are to Wifi. In Dili we couldn’t set up a 300m link between MPs equipped with Omni-directional antennas due to massive interference. Even to obtain that range with directional antennas we needed huge, free standing masts (up to 25m) to clear obstacles like trees. However “on the beach” we can achieve an impressive 2.1km with omnidirectional antennas and modest power levels. Links Coincidentally a couple of friends sent me this link on PCB antenna design while I was writing this post. By David Rowe, on July 11th, 2010
Yesterday I was a guest of the Serval team on an exciting field deployment in the Northern Flinders Ranges. It was a very busy day, starting at 4:30am and flying out at first light from Adelaide 700km north to Arkaroola in a delightful Pilatus PC12.  Pilatus PC12 at Aldinga Airport  Flying to Arkaroola One hour and 20 minutes later we were guests of the Arkaroola Sanctuary who delivered us via bus, 4WD and helicopter to various locations for trials of the Serval technology. The Arkaroola people were very excited and very helpful. One thing I love about the Village Telco is the good will it generates. Once the project is explained people go out of their way to help you. Projects with social rather than commercial aims are so much more satisfying to work on. The silence at Arkaroola is amazing. Remote and sparsely populated wilderness. Nice terrain for Wifi too – lots of hills and no trees.  Helicopter from Sillers Lookout Serval is a system for rapid deployment of phone networks in disaster relief scenarios. Serval uses Village Telco technology (mesh telephone networks) combined with several new innovations. One is Distributed Numbering Architecture (DNA), a way to assign existing cell phone numbers to your phone on the mesh network. The Serval team has hacked Android mobile phones so they work as mesh telephony devices. This involved porting Batman and Asterisk to Android. Very impressive and very cool.  Dany Testing at Flinders University The result (so far) is a cool numbering scheme where you can assign phone numbers in the field without a server and the worlds 2nd mesh telephony devices (and first mobile mesh telephony devices). The “Serval Batphones” integrate seamlessly with Mesh Potatoes. The DNA software can also run on Mesh Potatoes. Future work will involve using OpenBTS to integrate GSM connectivity. The Serval team is lead by Dr. Paul Gardner-Stephen from Flinders University. Paul, Romana Challans and Dany Rakotopara (a talented French exchange student) have been working crazy hours to get everything coded, integrated, and to organise the amazing 1-day field trip we had yesterday.  Paul and Dany developing Serval Serval is partially supported by Flinders University (thanks for funding this demo trip) with large chunks of volunteer effort by the Serval team. The story was exciting enough to attract a local ABC TV crew to join us. I was really impressed with the way Paul, Romana, and the University media department coordinated the media side. Serval and the Village Telco is a great story. This is a point I often miss. I freely admit I am “too much of an engineer” and don’t appreciate the strong media value of our project and the leverage it can provide. The demos involved three scenarios for rapid deployment of telephone networks; (i) disaster relief, (ii) search and rescue, and (iii) deploying networks in difficult terrain. I learnt a lot yesterday by talking to Paul and the team: Wifi and Android penetration in handsets is growing rapidly. This means that in a few years all phones could have mesh telephony built in. Every cell phone could be a “Batphone”. Mesh Potatoes in fixed locations can be deployed quickly in strategic locations to relay the phone calls and blanket areas with a mesh network. You can then use your existing phone handset to make calls on an ad-hoc Wifi mesh network.  Serval Bat Phone at Arkaroola This is a first world twist on the developing world focus of the Village Telco. In the developing world the Mesh Potato will be the telephony device and it’s low cost is an important factor. However in the first world everyone already has a handset. So it makes sense to use them in a disaster relief scenario. Key points here are high mobile phone handset penetration (everyone carries one) and the low cost of mesh Wifi networks. The demos yesterday used less than $2000 worth of equipment (Android phones from eBay and Mesh Potatoes) to form a phone network covering 1 square km.  Eye of the Potato: A Mesh Potato overlooking Arkaroola Village I find it very satisfying that Village Telco technology can be quickly combined with other technologies like Serval. Try forking GSM and you will see what I mean. Accelerated, unencumbered development using Village Telco tech is possible because it is is fully open and uses unlicensed spectrum. Derivative projects like Serval are just the beginning. As I flitted over the beautiful arid landscape in a small helicopter the thought “What hath Steve wrought” (apologies to Samuel Morse and Steve Song) flashed through my mind.  Helicopter at Sillers Lookout  Testing in the bush  Bus to Arkaroola Village  Romana being interviewed for the Serval documentary  Dany enjoying the helicopter  Paul and The ABC TV crew  Potato Tree - 4AH Lipo battery is a great idea  4WD trip to the Observatory By Steve Song, on June 23rd, 2010
One of the challenges in making the Mesh Potato as dead simple to use as possible is the fact that, unlike many modern Internet devices, it has no GUI. Sure, you can plug a laptop into the ethernet port or connect via WiFi to a web interface but the Mesh Potato on its own has no GUI, which presents certain challenges in designing a drop dead easy-to-use device. However, constraint can be both a barrier and an enabler of innovation and this is certainly true of the Mesh Potato. As it turns out, we are only just beginning to discover the potential of the voice interface to the Mesh Potato to improve user experience. Here is a great example. The first thing you want to do when you power up a Mesh Potato is make sure it has a good connection to its peers. This is easy if you have a GUI or even a command line but what if you just have a telephone handset? David Rowe developed a script for his deployment of the Dili Village Telco that continuously polled the quality of the mesh link on the MP. Elektra has taken that one further and integrated the script into a voice interface that give continuous audio feedback on link quality making it easy to tune your WiFi connection with a simple handset. Here’s a brief video of me testing out this feature. Tuning Mesh Potato WiFi Performance with a Voice User Interface from Steve Song on Vimeo. By David Rowe, on June 4th, 2010
Paul Gardner-Stephen had one of his MP01s “brick up” when attempting a GUI-based reflash and was having problems recovering. So I offered to take a look at it for him. Reflashing and recovery can be intimidating the first time around so I thought a short blog post might be useful to explain the steps I took to bring his potato back to life. I also hit a FXS driver/hardware problem. The steps I took show how to debug the FXS part of your potato. Paul had made several attempts at reflashing and was concerned that he had zapped the boot loader. So to check the boot loader I took the optional (and usually unnecessary) step of connecting a RS232 daughter board to his MP01:  Mesh Potato Serial Port Access Due to the shape of the RS232 daughter board I had to remove the MP01 PCB from it’s metal box. The RS232 daughter boards are the same as the IP04 so I have many laying around, however they don’t ship as standard with Mesh Potatoes (let me know if you ever need one). The serial settings are 9600 baud, 8 data bits, 1 stop bit, no parity. Anyway I applied power and after a few seconds I saw the expected boot loader output:
RedBoot(tm) bootstrap and debug environment [ROMRAM] Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc. Board: ap61 The last line is the boot loader loading the Linux kernel. However Linux wasn’t coming up, probably due to a dud image. So the next step was to try reflashing. My favourite reflash method is documented here on the Dili Village Telco Wiki. It has also been discussed at length on the Village Telco Google Group. There are actually several ways to flash a potato but this way is my favourite and has proven very simple and reliable in practice. It’s a very good idea to practice reflashing before you actually need it, as an exercise. After reflashing Paul’s MP came right up. I telneted 192.168.1.20 and could see Asterisk running (using ps x) however the phone was dead. No evidence of power to the phone and no dial tone. I used “dmesg” to check what the FXS drivers where doing:
Hmmm, these zeroes at “reg0″ and “part number” don’t look good. This indicates the FXS driver can’t read registers on the FXS module. After poking around for a while I discovered the J1 jumper was not installed. This jumper connects the clock to the FXS module. I replaced this jumper and rebooted and the driver output looked better:
This is what you should see for a working FXS driver. The phone was now powered up, and dial tone was present. Hmmm, might be a good idea to print an obvious error message when the wrong register values are found! To configure a MP01 I actually find it easier to telnet 192.168.1.20 and use vi to edit /etc/config/wireless and /etc/config/network, then run /etc/init.d/network/restart. But many people like the GUI, it’s your choice. I changed the Wifi Channel and BSSID to match my local mesh network and made a few test phones calls. Looks good, so I will send the MP01 back to Paul. By Steve Song, on June 3rd, 2010
We’re getting closer and closer to full production of the Mesh Potato. Below you see the 1.3 version of the Mesh Potato motherboard that integrates the FXS module onto the PCB and also includes an integrated antenna on the PCB as opposed to the external antenna for the first Mesh Potato prototypes. We chose to integrate the antenna both to save production costs but also to improve the weather-proofing of the Mesh Potato; one less joint exposed to the elements. By Elektra Aichele, on February 19th, 2010
We have now a new over-voltage protection circuit design for the mass production Mesh-Potatos. We were not satisfied with the previous version. Ideally the over-voltage protection circuit has a snap-on characteristic that triggers the fuse and interrupts the supply voltage without a grey zone. The new circuit triggers at 43 Volts and acts as a powerful crowbar circuit. I have connected the prototype of this circuit to a Mesh-Potato and went through the robustness tests according to our test plan. You can find the test plan and the schematic in the svn respository. A little video at Vimeo.com is documenting some of the tests – thanks to Katrin Lang, who acted as editor and camera operator this time. Mesh-Potato smoke testing with 230 Volt AC from Elektra Berlin on Vimeo. The list of tests included a reverse DC voltage test from a unfused 36 Volt source (consisting of three powerful 12 V lead acid batteries in series), excessive DC voltage tests and finally a really scary test involving 230 Volt AC (330 Volt peak) from mains. Please don’t try this at home. Even if the Mesh-Potato survives, there is a 50% chance that you might have mains potential on ground of all components connected to the MP. Also don’t try this with your alpha or beta series Mesh-Potatos, because the previous over-voltage protection circuit is not up to that challenge. Technically inexperienced people can easily make mistakes, so our idea was to design the Mesh-Potato as robust as possible. In 2005 I was helping to set up a large scale WLAN network in the Sylhet area in Bangladesh. The network consisted of high towers (up to 100 feet tall) and strong directional antennas, interconnecting towns and a school with wireless long shots (up to 32km). One of the trainees damaged a important wireless relay on a tower by taking the open ends of a 12 Volt cable and plugging it straight into the mains socket. Of course the equipment (a Mesh-Cube from 4G Systems) subsequently looked like a lightning strike had hit it, which was actually what I supposed first. However there had been no thunderstorm in the night before. It took me a while to find the reason. The trainee either hadn’t realized what he had done, or he didn’t want to admit it. He watched me trying to find the problem without saying anything. It is common practice in Bangladesh to plug cables into sockets without plugs. The quality of sockets and plugs is miserable, so loose contacts are the rule, not the exception. Now a important relay was down and it was hard to get a replacement. The problem wasn’t so much the financial loss. Shipping and particularly customs can take weeks in Bangladesh. So during the first Villagetelco workshop I suggested to design the MP as robust as possible. By David Rowe, on January 30th, 2010
I have just returned from LCA 2010 where I presented on the Village Telco and manned a Village Telco booth on the Open Day. Very good response and lots of people would like Mesh Potatoes! Check out my LCA 2010 blog post for more.  Mesh Potatoes at the LCA 2010 Open Day By David Rowe, on January 14th, 2010
Today we made some phone calls over a 400m link using PCB antennas. We want to use etched PCB Wifi antennas for the Mesh Potato. However we have heard that some companies have had problems with PCB antennas, such as variable results in production. So before committing to PCB antenna we wanted to do some more tests. Joel is a local hacker here in Adelaide who happens to live at the top of a 4 story apartment block in a beach side suburb called Henley Beach. This gives him good line of sight to points on the ground several hundred meters away. Much easier than testing at my place which is on dead flat terrain and requires masts for any Wifi range testing. Before heading out to Joel’s place I tried some tests in my backyard. I set up two MP01s about 10m apart. First I connected conventional sleeve dipole (rubber ducky) antennas and measured the signal strength. I then connected a couple of PCB antennas and repeated. To monitor signal levels I wrote a simple script to dump the Received Signal Strength Indication (RSSI) levels (in dBm) from MadWifi: while [ 1 ] The grep filters out the last few MAC digits of the MP we are interested in, otherwise you get RSSI measurements of all nearby Wifi devices. However the results were inconclusive and after an hour I became frustrated:
I had much better (and less frustrating) results using the spectrum analyser to measure signal strengths, as explained in the previous post on PCB Wifi antennas. In the end I figured it was sufficient to test from a system level rather than attempt more measurements of antenna performance and signal strength. The $64 dollar question is can we make phone calls over a reasonable distance with these antennas? On the Beach We placed one MP01 on Joel’s balcony. I then walked down to the end of Henley Jetty (Joel has previously managed to pick up his home Wifi there). There is (just) a line of site between the two points – through a gap in a couple of buildings. The distance was 375m. We used two calibrated V1.2 MP01s (same design as the Beta units). An “iwlist ath0 scan” showed 9 other Wifi networks in operation.  Google Map of Range Test - 375m  One MP01 on Joel's Balcony I tried a bunch of antenna combinations, starting with regular sleeve dipole (rubber ducky) antennas then moving to PCB antennas first at one end, then both ends of the link. From our previous tests both the sleeve dipole and the PCB monopole antennas have an estimated gain of 2dBi. We had a total of 4 PCB antenna samples (a mixture of the 17mm and 20mm monopoles) as we wanted to get a feel for performance spread over multiple antennas of the same design. Here are the results:
The final test was just to make sure we weren’t kidding ourselves.  MP01 on the end of Henley Jetty At one stage a fisherman assisted in my propagation experiments by standing right in my line of site and lowering a metal net as I talked to Joel! For each call I tried moving the MP01 (with PCB antenna attached) around. For example upside down, side to side, rotated it. No break up of signal, good audio in both directions. Only problem was wind noise. Joel suggested we add digital noise suppression but I figure there isn’t much wind noise inside village homes! Here is the view of the far end from either side of the link. The arrow shows the location of the other end.  View of Jetty from Joel's Balcony  View of Joel's Balcony from Jetty That's him with the brown eyes. By David Rowe, on January 13th, 2010
Joel is helping my Village Telco presentation at the upcoming LCA 2010 conference so I took a couple of the first Beta MP01s down to his place for a test drive. They are fresh off the production line and not even calibrated as I needed them in a hurry for LCA 2010. Atcom are currently assembling, testing and calibrating the Betas which will be shipping over the next few weeks.  The first Beta Mesh Potato These early Betas are running revision 203 firmware, which has Afrimesh as the primary GUI with Luci available for “advanced” configuration options. Thanks Elektra and Antoine for your fine work on the Mesh Potato GUI. Here is Joel’s experience – our #1 Beta MP01 tester! Joel is pretty geeky (he has contributed for several years to the OLPC project) but has never used a Mesh Potato before. I hope this information will be useful for other Beta testers who should be getting their Mesh Potatoes over the next few weeks. I stood back through most of Joel’s beta experience – I wanted to see how other people approach the Mesh Potato. How Joel Configured His Mesh Potato
That’s it – the main step is just change the mesh Wifi IP to something other than 10.130.20. Then reboot and you can start making calls between Mesh potatoes. Easier Configuration A slightly easier way is:
Configuration without a Web browser
Joel asked a good question – what do all the LEDs mean? They are not labeled although from memory it’s power/Ethernet/Wifi activity etc. I asked Edwin@Atcom about this and the reason was the vinyl labels hadn’t arrived when the first few betas shipped. The rest of the Betas will have these labels for the LEDs. |
||||||||||||||||||||||||||||||||||||||
|
Copyright © 2010 Village Telco - All Rights Reserved |
|||||||||||||||||||||||||||||||||||||||
