Mesh Potato field trials

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.