That would be my personal opinion yes.

That is not to say Pi's don't have a purpose, I'm an early adopter I've got several of the Rev1 Model B's (256mb ram old pinout) that have proven themselves very useful over the years.

I use one for my display system and for teleneting around my local developer test network and for sshing into my BBHN compile lab. 

I can see Pi's being good servers for a lot of applications (I tend to recommend against running services on node) there are some things a Pi can't do but a lot of things they can.

As much as I kind of wish I didn't read that, I am glad you cleared that all up. That does make other solutions look better when it comes to cost. So, however it is that a person plans to build a mesh, a Pi probably shouldn't be at the top of the list then huh? :)

Still going to need to get a Pi2 B so that I can use it as a HTPC. ;)

It's a complex issue.  Here's an article that could shed some light on mesh throughput and the rates you've been seeing: http://centmesh.csc.ncsu.edu/course_report2.pdf

Andre, K6AH

Thanks Jim,

I figured I would have to add that route to ALL nodes, but how to make it persistent when the node reboots?

I suspect for in the wild nodes you will find Ubiquiti cheaper after you consider the following list of supplies

Pi - 35$

SSD CARD - 20$ (depends on size and performance)

Outdoor Case - 50$ (cooling/heating/case/etc)

Switching Power Suppply - 25$ (12v to 5v).  One may be able to use a LM317 but would need a large heatsink because of the 1amp current draw (less than 40% efficiency on this circuit)

Wifi Card - Varies. Most only have a single antenna port meaning you can NOT get extra MIMO RX/TX performance. I did see one dual antenna model on eBay for 20$ but it looks to lack FCC so one would wonder how well it is built, we don't need FCC for HAM but a lot of non certified gear is very poorly built.

The list goes on.  If you do want to run one as a mesh node you should look at the HSMM-Pi project as we do not build a pi install at this time.

As noted, Stock AirOS will go up to 40mhz wide channels that will be part of it as we are not currently supporting 40MHz Channels (the hardware will do it but we haven't seen much need for 40MHz yet, if anything it's the 5/10 that have the focus right now)

MCS Data rate should kick in however also note that other wifi traffic can slow it down.

I haven't had time to do a benchmark lately so I'm not sure if you are seeing limitations in your setup or some other item.

Try adding a static route 44.0.0.0/8   gateway={IP of WAN port/VLAN}. If that works, The drawback is you would have to add that route to any node on your mesh you want able to see the 44's, pointing the gateway setting to the node able to talk to the 44 net.

Thats the same way I tell my PC on my LAN how to access the 10.x.x.x mesh, through a node on the LAN (LAN/Mesh GW node).

So, Raspberry Pi2 B has just been released. I am looking forward to getting one of these for now to play with and use for many projects. Eventually I am sure I'll have a pile of these things all over the place. Anyway, my particular interest right now is using them as mesh nodes. A guy contacted me recently (deleted the emails) and he was using the Pi's for mesh nodes. For him and his application, this was the best solution for him. This got me thinking...

Is there a guide or something that explains (perhaps shows) how to setup Pi's to operate as mesh nodes? What hardware (antennas and such) that can be used? Maybe even what power can be used since these would be placed "in the wild"?

Any help on this would be greatly appreciated. I just cant seem to find answers to all of that and thought that someone here may have something to say about it. :)

Thanks

Indeed.

Which is why we also tested UBIQUITI to UBIQUITI alone, without any linksys on the mesh and yet we achieved the same speeds achieved when we tested the mesh using only linksys devices.

This cannot be because we know ubiquiti to ubiquiti transfer rate should be much faster than linksys to linksys.

We cannot understand why uniquiti is still performing at 15Mbt/s, just like when we tested linksys to linksys.

Following last month's disappointing results with the range of our mesh nodes during the Cuddeback Dry Lake Exercise (see the After Action Report in the General Section of the Forum) some of the members of the Land Ops offroad club are going to run some tests on Saturday, February 7 to determine the best configuration and the practical range of the mesh nodes with various antenna configurations over typical desert terrain.  Members of this forum are welcome to join us and bring your mesh node equipment or just bring your expertise or curiosity and see what kind of distance we can get with our equipment.  Our nodes are flashed with v3.0.0 of the firmware.

We will be meeting at Christmas Circle in Borrego Springs at 10:00 am PST on Saturday, February 7.  Look for vehicles with Land Ops decals and people with Land Ops T-Shirts.  We will be on 145.525 simplex. We have identified five locations that are on or adjacent to paved roads and six locations that are on easy dirt roads that we would like to use for node testing.  Even if you don't have an offroad vehicle you could still participate or observe the testing at those sites that are on paved roads.

Some of us will meet for breakfast at 9:00 am at Kendall's Cafe, 587 Palm Canyon Drive, Suite 120, Borrego Springs.  It's about a block west of Christmas Circle.  http://kendallscafe.net

I have it partially working, have assigned one of my AMPRNET assigned IP addresses to the Gateway BBHN node that is connected to the AMPRnet.

Devices attached TO THAT NODE are able to access the AMPRnet, even though they are using the DHCP addresses assigned by the BBHN node in the 10.x.x.x range.

Devices on the mesh that are NOT directly on that GW node are NOT able to access the 44 net.

I am trying to figure out what kind of creative routing has to be manually entered into the mesh nodes so they will know how to route that traffic.   I also have another mesh node configured as a GW thru the ISP to access the Internet at large. 

The final plan is to have the mesh route Internet traffic out the GW node that is connected to the Internet, and AMPRnet traffic out the node that is actually a GW to the AMPRnet.

I assume this will have to be manually entered in a console, as there are very limited settings in the configuration page.

Any ideas?

Thanks!

Along with running on multiple RF channels you can also get some of the RF armor kits which are metal shields to go around the NanoStation (and other models) which can help attenuate signals from nodes below/above/behind since the node case is mostly plastic it adds some extra protection.

Both of these are tricks that WISP's use to put multiple devices on the same tower however the use of different channels is probably the best of them all and the armor is an added bonus.

If your area uses smaller channel widths you can fit more nodes on a tower at the expense of slower speed (you also gain extra spectral density which improves the link performance )

on each of your nodes...

ssh into your nodes:

cd /www/cgi-bin
wget http://www.k5dlq.info/mesh/sysinfo.json
chmod +x sysinfo.json

Now, on a PC/Mac/Linux box, etc with Python installed....

wget http://www.k5dlq.info/mesh/meshcrawler.py
python meshcrawler.py

Enjoy.

I would suggest at least using a reverse-ethernet cable to connect the LAN ports on the two power bricks. That is really the same as using a switch/hub, but a lot less expensive. OTOH, a switch/hub does let you get in the middle with your computer if you want. Also, I think you indicated that the mid-point was also your gateway - in which case, you'd definitely want a switch.

Also, personally, I'd just try both radios on the same pole with as much vertical separation as you have available. You will probably get de-sense, but you may still get a usable link. Even better, if you can run one pair of nodes on ch 1 and the other on ch 6 (or ch 11 if you can run under Part 15 rules), you should get improved isolation.

YMMV, good luck.

!st disclaimer - I do not know much about what I am talking about . . .But I have run a linksys behind (in back of) my NSM2 and it works well. Based on your diagram, I would just mount the two NSM2s somewhat back to back and try them without the switch that you show. Just may save a piece of equipment. Do not know what difference a PVC pole mount would make vs a metal pole. You may need some separation - Mine were 20 feet apart.  Good Luck!

Vance, KC8RGO

Hm, ok I'll have to look at it later on one of my nodes to see what is going on as I would think that would do it.

But, of course ;-)

Did you restart the firewall after editing ? (/etc/init.d/firewall restart&) 

Thanks for the information.  I had seen the signal strength data in brackets and thought it was some kind of high/low/avg - well, basically I didn't know what it was.  Now I do!

I agree, the topology should be the same on every node. But, it seems that if the net is not particularly resilient, some of the links do not propagate around the mesh.  Also, graphviz seems to like to place the local node at the top of the graph.  Sometimes it would be nice to change that -- even if only for political reasons ;-)  And... thanks for the clarity on the port numbering.  I see that now in the inetd config.

BTW, I tried adding the following to the firewall config, but no joy.

config rule
  option src 'wifi'
  option dest_port '2004'
  option proto 'tcp'
  option target 'ACCEPT'