Today was mesh day! Finally we had a few hours free to all get together and do some long distance mesh potato testing. There was a lot going on during the day, and we did some different tests so let me setup things by giving you details of the test environment and what we looked to get out of it.

The test we had in mind was to see how far we can throw decent signals with our stock mesh potato units. We have been playing with them in the confines of a single room for a while now and have them singing and dancing but out in the real world what kind of distances can we get. The ideal way for us to start was to challenge the god’s of wifi and set up our 3 units in a way where they had good spacing apart, and only two units could see each other at a time.

Site A was in Dee Why, being manned by Glen and Dave. This is where we started in the morning to do our testing. Site B was at Long Reef headland, manned by Geoff. Site C was in Collaroy, manned by Carlo. The idea was to get fairly equal spacing between us, but have site B as the man in the middle to mesh Collaroy and Dee Why together. We had 2meter amateur radio handhelds to use for comm’s (with Geoff acting as relay) until we had the mesh up and running for voice.

The setup was the same at each site, a Mesh Potato on a stick of some kind (Squid Poles), Analogue phones for voice and laptops for running network performance testing (iperf / jperf).

Setup

Getting setup wasn’t too painful. All three units are using slightly different methods of power connection which is good for experimentation. The only hiccup was one mesh (the one I was holding onto) had a slightly different firmware to the other units, which may or may not be the reason why it didn’t want to mesh with the other two units. Glen re-flashed my unit with the same software and that resolved the issue. In field use it would be likely that we would all have the same code so no biggie on that one. One thing that we have noticed is flashing the units from a ubuntu virtual machine (with vmware fusion) can throw some funny errors, this time around it didn’t slow us down but it seems a switch in the middle of the equation may see the flashing process work better.)

Glen and Dave had site A up and running very quick. Located at the headland car park it was also one of our most visible sites. The guys got asked a few questions by the locals, some of which jokingly asked if we were installing the NBN. We of course answered yes whilst poorly attempting to hold a deadpan face (We recently found out our suburb’s are not included in the 3 year roll out plan…).

Testing & Results

So the plan was to get the mesh up and running, and once we could ping each other run some tests. Site A and Site B were around 2.1 km apart and connected up. Site B and Site C never connected even after the power was bumped up.

Site A and Site B were able to chat away on the analogue phones with a little crackle and line quality issues. Glen being the resident voice comms guru tried a few different codec’s to see if he could improve the voice quality, but it seems most of the issue was the underlying link quality.

The link speed bounced around a little too. It didn’t like TCP packets much, but could handle UDP packets much nicer.

Between Site A and Site B the maximum throughput was around 1Meg, but as you can see with the first image below it was short lived. The average generally was closer to between 250 – 500 KBit’s. Remember this is over a 2.1KM link with 2 standard mesh potatos with no external antennas etc etc. For the test Site A was connected to the Mesh Potato via Ethernet, but Site B was connected via wifi.

Dave did some other testing, here you can see ping results from his mac to Geoff’s PC. Not a bad response time when both computers where connected to their respective Mesh Potato’s via wifi. Dave’s Mac could also see Site B’s Mesh Potato in its wireless list, but he couldn’t connect to it.

Glen noticed a failure of the link at one stage during the testing, after looking up he quickly established a potential cause. This little guy really wasn’t too interested in giving up his vantage point.

So what did we learn?

That these things are great radios, and we took them to the edge of their performance today. 2.1km out of a little wifi AP is a great result, and we are very happy with the results. The main lessons learned could be summarised as

1. When operating in the field make sure all your units are on the same code.
2. 2.1KM is a great result, but ideally these units would be placed closer together or have external antenna’s to improve gain.
3. Field operation probably takes a little more preparation on the testing we where going to run. Next time we do a prep hour or so indoors in ideal conditions testing the commands we are going to run and how we are going to record the results.

Things to try / improve

1. Run some more controlled area tests to figure out the max throughput of these units.
2. Make a prepared list of commands to run directly from the mesh. (Ie, Horst for wifi noise and wlan connection speeds between mesh units)
3. Same test as last time, but place Site C in the middle of Site A and Site B. That way we can see how the units mesh, and if they choose the faster path correctly.
4. Create a cheat sheet of commands, numbers, IP’s and passwords.
5. Figure out if we can write some scripts to query the units and dump results.
6. Do a debrief immediately after the tests to get it all down.

Lab Results

Glen ran some tests between his two units across his apartment and found that he could move 15mbit of traffic, so the hardware it self is great.

Here you can see the results Glen got when he did some two way tests between two computers connected to individual mesh potatos that had meshed together. As you can see they can get a very decent throughput, this is 15MBits both way with minimal jitter. Obviously they are in the same room but it shows the hardware is capable of nice things.

Anyway it was a great day out, we had a lot of fun and it was great to nerd it up in the sun.

http://nerdpolytechnic.org/2012/04/meshed-potatoes/

One of the early mistakes we made with the Mesh Potato was not placing sufficient emphasis early on, on getting type approval for the Mesh Potato and indeed focusing on both European and U.S. type approval.  What is type approval you ask?  Type approval is the magic glue that makes unlicensed spectrum work.  Many people take the term unlicensed to mean unregulated but nothing could be further from the the truth.  Unlicensed spectrum succeeds because the devices that are permitted to use unlicensed spectrum are carefully regulated to ensure that they conform to strict standards in terms of power output and many other technical specifications that ensure that unlicensed devices “play nicely” with each other.

I am happy to say that this issued has finally been addressed in full and Mesh Potatoes now enjoy full compliance with both the standards of the Federal Communications Commission (FCC) of the United States and the European Union’s CE standard.  These are the two most common international standards for compliance and should ensure that the Mesh Potato can conform to almost any regulatory regime.

If you would like to get copies of the certification in order to apply for local type approval in your country, please get in contact with us via this website.

SPUD is a PHP based dashboard that communicates with the BATMAN visualization server and displays real time wireless link status. The software is written in CakePHP (a PHP-based MVC framework) and uses Google Maps API 1.3 for visualization.

SPUD is designed to be as simple as possible to use, and to enable teams, that have installed large amount of mesh nodes, to visualize their networks quickly.

Some of the core features of SPUD are:

• Client management: Bulk import of clients from CSV file, Edit client position with Google Maps, Tracking of new clients
• Link monitoring: Easy overview of active wireless links, Mesh quality in each direction of a wireless link
• Customization: Colours and threshold values for link quality

See above and below for screenshots that shows some of the functionality of SPUD.  The source code is available via SVN at

svn co http://dev.villagetelco.org/svn/villagetelco/spud/trunk/

and the default configuration will monitor our demo site in Bo Kaap (Cape Town)

Detailed installation instructions are available at

http://spud.villagetelco.org/install (user: vt-admin pass: ouagadougou) or http://dev.villagetelco.org/trac/wiki/spud_install

We have set up a demo site of SPUD that visualizes the Bo Kaap network. The demo is available at: http://spud.villagatelco.org. Please feel free to play with it, and provide us your feedback!

We headed for Tankwa Town with a full load and empty wallet and flashed & configured the Mesh Potatoes (MPs) in the desert using the good ol’ 192.168 range. The booths were different to last year: they had production MPs, new sleeves and no lighting. I set each node with a different Virtual Access Point (VAP) SSID based on the phone number because I found that using an identical VAP SSID caused SSH to die. This will be ideal in the future, when each MP owner has a WPA key on their router and both cabled and VAP connections are linked to the same account. So any device that wants to roam must either switch between VAPs or run batman itself.

Steve came up for 2 days to help set up and bring some much-needed supplies. I discovered that an Olmeca tequila bottle is not as sturdy as it looks. It broke in the trailer and softened up the Tetrapak milk until most of the cartons ruptured too. So a Nano, a few phones and other gear were swamped. Thanks for the rescue, Steve.

We set up the booths easily this year – far less wiring and better ground pegs. We put phones in the organiser’s caravan, medics and the gate, with a Nano to cover the 5km distance to the gate. However this year they had moved the gate to the end of the airstrip, so it was only 1km away.

I had brought a netbook with broken screen to act as gateway, redirecting all port 80 traffic to a phpbb3 bulletin board with the appropriate DirtyBoard2.0 skin – see http://swug.za.net/phpbb/. I also redirected port 53 to dnsmasq that spoofed the DNS of  Top Level Domains (TLDs) to the gateway IP too. These are the kinds of things that naughty people do, but I think it works well for our application. I set each router’s dns as 8.8.8.8 and SIP registration to villagetelco.org. When a mesh is connected to the Internet, DNS & SIP will work fine (once VT has a SIP server). If there is no Internet access, DNS/SIP/HTTP can be fielded by an offline gateway server. It does look a bit odd, but it works.

The spoof gateway was running fine for devices connected to the LAN but was not accessible from the WAN. In fact, no other device connected to a different MP could be seen except for the MP’s LAN address itself. This suggested that there was an issue with the dummy gateway setting on the LAN, required to allow Asterisk to run as per David & Elektra’s discussion

I was 4 days into the trip by then and it was time to party, so I left the gateway for another day – and Internet access. It was most helpful though in checking the booths. Instead of plugging in a netbook, one could just pick a nearby cosy camp, settle down and connect wirelessly. DHCP, LAN bridging, batman routing, Asterisk were all working fine.

Solar operation

This year I invested in a 90W monocrystalline solar panel and regulator for the camp – 90 watts when the sun is shining for the next 25-50 years. It will be part of my home solar office in a few weeks. I had 4 105AH tractor batteries from last year and connected the gateway netbook and the fixed one (20-40W each), plus about 20W of lighting and didn’t have a power problem for the whole week.

We used the 10W flexible solar panels and 12AH batteries on the booths as with last year, but this time there was no lighting in the booths. 10W kept the booth MPs up throughout the week, but the batteries drained progressively. I put this down to the number of phone calls being made – nearly all the time, day & night. One booth’s phone was left off-hook providing dialtone for a few hours. I disconnected it for a charge back at camp and it was sorted. Perhaps a dialtone hangup can be written into Asterisk for such events on battery-powered phones.

I also installed a phone in a friend’s art car, connected to the cigarette lighter adapter. It was great to be able to phone the art car from anywhere and ask for a pick-up. However next year, I’ll bring along some battery clips so that the phone stays on when the car is off – see whether the MP can “survive the crank”.

Conclusion

This year was tougher with just Steve and I setting up, but easier because of the work we could build on from last year. The most promising result from this year were that the phones worked and worked hard. It gave me some time to work towards the 4093-node, no-NAT VAP firmware I long for. Although the VAP was not feeding into the gateway, every person with a wifi-enabled laptop or phone saw hotspots – so hopefully they’ll be better prepared next time too. Comments from participants were different this year too. Last year the phones were a novelty; this year people were more interested in and supportive of the technology behind the phones.

This year I met some important people for next year. Adriaan Wessels is the technical chap on the organising committee. For next year, we’ll be able to plan carefully regarding gate link and possibly organiser car links. Organiser confidence in the network will mean that they will be able to pre-announce a “Tankwanet” and its services so that participants can be better prepared to take advantage. There are a lot of IT geeks at Afrikaburn. Perhaps some of them could be persuaded to offer services on the network.

Rod Bracher runs the Tankwa Town post office, Burning Mail. They have some old rotary-dialling phones that they connect with carrier but without dialling. I tried to coordinate with him to hook his phones up to the network, but ran out of time. We had a chat about doing so at this burn, so pulse-dialling is definitely on for next year.

The streaming services company antfarm.co.za were at AfrikaBurn this year. I couldn’t spot their VSAT dish, but made brief contact. They were streaming the burns live, which led me to figure a rule at AfrikaBurn: the isolation is an important part of the event, but the isolation need only exist one way – incoming. So theoretically, participants should be able to send SMSs, update their twitter accounts and post on a forum on the Internet – as long as they don’t see any response from outside the burn. Antfarm’s ISP only allows Internet connection on port 80, so a little port jiggling and a helpful Internet server should squeeze whatever we need through, except for multiport SIP.

Lastly and simply, Isigidimi was at AB2011. The continuity will help us attract more participants next year, and perhaps more of the VT-dev community. You can set up an Asterisk service, website, jabberd, tinker with pulse-dialling, or just sip on the Kool Aid and be inspired ;^)

Here are some more images from Afrikaburn 2011

Setting “smart defaults” is a key to masking complexity and lowering the barrier to uptake.  Think of Google’s search minimalism after Altavista et al or Apple’s simplification of so many applications that were filled with twiddly knobs, checkboxes, and radio buttons in other operating systems that shall remain nameless.    Wordpress is another great example of an application that is capable of impressive sophistication for “blogging software” yet pretty much “just works” after completely a bare minimum of setup information. Terry has taken us one giant step closer towards WordPress-like usability with his Small Enterprise – Campus Network (SECN) setup for Mesh Potatoes.

His goal to be able to serve a local network of modest size offering seamless voice and data.  He wanted any Mesh Potato to pick up Internet connectivity via the ethernet port, if it could find it, and for each Mesh Potato to offer a local WiFi access point.  After experimenting a little bit, he chose to install the BATMAN-ADV mesh protocol instead of BATMAN protocol we currently use.  The big difference between the two protocols is that BATMAN-ADV runs at Layer 2 and BATMAN at Layer 3 of the OSI layer model.  What does that mean?  Well the simplest explanation is that BATMAN-ADV makes Mesh Potatoes behave as if they were all part of one big network switch which means that IP addressing and routing for the network is dramatically simplified as each Mesh Potato is effectively transparent to the IP network.  This effectively removes the hassle of figuring out network addressing and Network Address Translation for Mesh Potatoes.  Everything is just one flat network which means that devices can easily communicate with each other on the network.  The flip side of this is that you have to be careful about what you put on the network because a poorly configured or worse infected computer can generate a lot of local network traffic.  This is something we’re exploring but for a small network, BATMAN-ADV seems to work exceedingly well.

With Terry’s modifications, an SECN configured Mesh Potato network will now:

• offer an encrypted, WPA-enabled, wireless access point as well as a peer-to-peer wireless connection on each mesh Potato.  This is done by creating a Virtual Access Point (VAP) on the same radio interface as the mesh.  Initially we chose not to enable this by default on the core Mesh Potato distribution because we were concerned about network data load have an impact on voice quality but Terry’s work makes me think that this was a mistake.  Much better to encourage use and solve the problem of over-use rather than ensure a functional but underused network;
• pick up a network connection from any DHCP-enabled Internet-connected device it is connected to the ethernet port on the Mesh Potato;
• transparently carry DHCP requests over the network to devices connected to Mesh Potatoes whether by ethernet or WiFi; and,
• offer simple on-network and also VoIP service provider configurable phone calling.  Local phones can be dialed simply by entering the last 3 digits of the IP address of the Mesh Potato you want to call or the Mesh Potatoes can be registered with any VoIP service provider.

The long and short of this is that if you plug in a bunch of SECN-configured Mesh Potatoes and make sure at least one is connected to something simple like a DHCP-enabled ADSL router, then you have a transparent, highly-adaptable technology for creating a robust local telephone and data network with no wires.

So, did Terry do this all by himself?  Without Terry’s interest and hard work at testing, reconfiguring, debugging the SECN version might never have happened but one of the great things about Open Source is that one is rarely starting from scratch.  He was able to build on the configuration that Elektra built for the Mesh Potato which in turn built on great Open Source initiatives like OpenWRT, Asterisk, and others.  And at least a dozen people in the Village Telco community were there to help him solve problems and answer questions.  Better still his work inspired others to try out new configurations with the Mesh Potato and Elektra was inspired to take the set of instructions that he had developed and embed them in a new Mesh Potato firmware distribution that people can use to set up smaller Village Telco networks to serve both voice and data.

If you’re interested in trying this out yourself, you’ll need a few Mesh Potatoes to start and then you’ll want to download the latest SECN firmware and flash the Mesh Potatoes with this new firmware.  Terry has been developing the documentation for the SECN, the latest version of which is here.  Because this is still at an early stage, that URL may change.  Best to check in with the Village Telco google group to find the latest version.

Comments welcome.

In terms of a place to pilot a Village Telco, it sits above the demographic we intended the Village Telco for but it seemed a good choice for a number of reasons:

1. There is a really strong community.  There are strong social bonds linking everyone in the Bo-kaap and strong social bonds means a strong desire to communicate locally.  This was the strongest motivator for choosing the Bo-kaap
2. We’re still learning and don’t want to create a dependency on something that is still evolving. The fact that Bo-kaap community is a little wealthier on average than our target community means that although they may value the Village Telco, they won’t be completely stuffed up if something goes wrong as we perfect the network.
3. It’s convenient.  Tempting as it is to set up a rural Village Telco right away, the Bo-kaap is not many minutes away for me so easy to get to and work on.

At the right you can see a screenshot from the Afrimesh software that we use to monitor the mesh.  Right now we’re up to about 50 nodes in the mesh and the increasing density continues to make things easier and easier.  In the beginning we had to be very careful about long links and used some Ubiquity Nanostation IIs to make some of the long shots.  We also had to be very careful about getting the Mesh Potatoes into a strategic position to pick-up other Mesh Potatoes.  Now, once I get up on someone’s roof, I can usually see a Mesh Potato in some direction so installation is as simple as finding something to attach the Mesh Potato to.  TV antenna’s have proven to be very convenient in this regard.

The installation process for the Bo-kaap has been slow, partly because it took a long time to get production Mesh Potatoes into our hand but also because the Bo-kaap is an old community and the houses in it have evolved more than they have been planned.  Each house is a little exercise in complexity in terms of getting to the roof, finding a cable path down from the roof, finding power near the desire location of the phone, etc.  I’ve got it down to a routine now though.  Having the right tools like a long concrete drill bit for going through walls are simple things that make life a lot easier.

We’re learning a lot as we install the Bo-kaap Village Telco.  We decided to offer 100 Mesh Potatoes to the community in exchange for user feedback on the Village Telco.  In order to build the most useful network possible, we built connections by following social ties, a bit like snowball sampling in research.  We started with a family that ran a cafe and followed their social ties, brothers, sisters, friends, neighbours.  Each new person is at liberty to suggest others.  By following existing strong social ties, the Village Telco immediately begins to delivery high-value connections.  An older mother-in-law that wants to stay in touch with her family who are only a few doors away but it is hard for her to get around.  A mother who recently became a grandmother wants to stay in touch with her daughter.  In each of these cases, they could use a mobile phone to call but like the majority of people in South Africa they are conscious of what time spent on the phone costs them.  A local Village Telco call is free.

Mesh Potatoes can be gateway-ed to other telecom networks and can also offer Internet services but for the time being we are just offering local voice because the devices do that on their own at no additional cost.  Once the community is ready to take over the network themselves and manage external voice and Internet charges, we’ll enable those other features.  Stand by for more from the Bo-kaap Village Telco.

You can see the final design of the Mesh Potato at the right.  Those of you are familiar with the Ubiquiti Nanostation II will know that we borrowed wholesale from their excellent enclosure design.  They say imitation is the sincerest form of flattery.  In this case, it is certainly true.  We love Ubiquiti gear.

What we’ve borrowed from Ubiquiti is the sealed-unit design which makes for a sturdy weather-proof enclosure.  What’s a little bit different is the back mounting which has a slip-on piece that can be screwed to a wall.  Without the screw-on piece there is a similar mounting to the Nanostation for mounting on a pole.

The best news of all is that Mesh Potatoes are now available for purchase by anyone.  Simply click on the Products link above to buy them from our webstore.  The cost of each Mesh Potato is USD 119 but for the next two weeks we’re making them available at the wholesale price of USD 89 per unit.  In order get that price, enter “afinemesh” as a coupon code on the Checkout page after you have selected the number of Mesh Potatoes that you’d like.  Shipping is calculated via DHL from Atcom in China.  Please contact us if you’d like to make other shipping arrangements.  Orders placed now will ship by the end of September.

Finally, I would just like to express ongoing amazement and appreciation of the many, many people who have contributed to making the Mesh Potato a reality in small ways and in big earth-shaking ways.  You know who you are.  You all seriously rock.  Open Software, Open Hardware refreshes the parts that other intellectual property regimes can’t reach.  Thank you.

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.
2. The Dili Village Telco Wiki.
3. Other blog posts in the Dili Village Telco series.

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

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:

• Height at Grange Jetty was 8m+4m mast
• Height at Henley Jetty was 8m+2m mast
• ping -s 1400 -c 100 21% loss 29/42/76 ms
• ping -c 100 7% loss 3/6/12 ms
• Batman metric 240-250
• “iwlist ath0 scan” detected 6 networks, between -81 and -95dBm

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.